SiteBrowser

SiteBrowser is a component of the Unnamed Grand Project. It presents the user with an interface like a web browser.

Ideas for components:

• Back button, Home button, history and navigation.
• Clock.
• Desktop-like area with user's "favourites" / bookmarks / desktop items?
• Key management? Somehow?
• Location bar.
• Site authentication bar?
• "Review this" widget?
• Tabs, for each page. This may be better done using bookmarks.

Client installation

The user downloads a client. When the client first "boots", it loads the SiteBrowser code from a remote site. This lets the SiteBrowser's implementation be modified at a later date.

The client would be SecureSqueak.

The client only implements a simple Canvas and event handler. The SiteBrowser code is given full access to the system, and after initialising, is responsible for managing dominions and implementing features such as navigation, user management and virtual consoles.

The client would have a simple REPLServer (i.e. command line) built in which is accessable through a key combination (alt-. maybe?). This lets the user have complete control over the local system.

Location / Lookup bar

This is where the user enters something like a URL. Entering plain words here will present either search results, or take the user directly to that registered site. Perhaps there could be two buttons - one for going there, and one for searching. The text field could also have other uses, e.g. to search local objects.

Once a user has found a page, that user would typically add that page to their bookmarks for future use.

Site hosters could register keywords, e.g. "Flowers". This would bring the user directly to their page.

People can register their sites for authentication (address verified, etc), which would also add a "review" link for that site. These sites would come up first in the search bar.

Keywords could be geographically separate. This could be by distance, or by country. If the keyword isn't registered locally, the search continues elsewhere.

Site hosters could initially purchase a keyword for a period of time. If a keyword is contested, it could be auctioned to the highest bidder for a period of time.

For example:

Keywords are registered for a trivial fee - e.g. $0.20/week. Anybody can register them. Anybody can register a keyword for a certain period of (pre-paid) time by putting a bid on it. The highest bidder becomes the default site, the other bidders have their sites come up in search results in order of their bids. Bids are public.

For fairness, the owner of a keyword has a period of time (5 days, taking weekends/holidays into account?) to respond to a hostile bid. After that grace period, the highest bidder then becomes the new owner of that keyword.

BrowserContext

Somehow, each site needs access to various local devices. Each device's API would be specified by... a version number? Perhaps the package linking could take care of this?

• The root canvas of the display. This is different for each site, making package linking interesting.
• Sound (speakers at 7.1 or more, microphones, other inputs, ...)
• Printers
• Mass storage (#filesystem1)
• Local dominions
• Other devices: webcams, scanners, joysticks, tablets, [multi-]touch screens, network (e.g. HTTP or TCP stuff somehow?), audio cdroms, ...
• Plug-ins such as OpenGL, video-conferencing, media codecs, ...