The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. (INTERNET PROTOCOL, RFC791)

The Internet is, as described in RFC791, a mechanism that enables messages to be sent directly from an end-point machine to another machine independently of the relationships among many intermediate routers. The Internet enables you to desirably build an end-to-end system which requires processing only at both ends. Based on the end-to-end structure of the Internet, the Web structure was created where Web pages on individual machines are connected with each other via hyperlink. This Web environment forms an “individual” using an end-point machine as a unit where information on a variety of activities is aggregated.

Bunsanweb treats this “individual” that is an aggregation of activities formed on the Web as a basic unit. Bunsanweb proposes an end-to-end distributed network that is the base structure for handling these individuals on the Web network.

One of the mechanisms of bunsanweb is a general-purpose reverse proxy for the Web. This system has not yet been given a name. This general-purpose reverse proxy mechanism consists of an intermediate program used as a general-purpose reverse proxy for programs that are externally inaccessible and the JavaScript library for an end point communicating with this intermediate program.

The general-purpose reverse proxy mechanism enables the user programs at end points to be accessed via an exclusive URI based on the hash value of a public key generated from their respective random number value. This intermediate program only requires the end point to add a self-signature to the hash value of the public key. Neither procedures for user authentication such as user account registration nor modification of a message during Web request processing is necessary. Therefore, even a small program that runs on a Web browser can behave desirably as an end point accessible on the Web by just being executed. For the backend implementation on this end point, ‘WebSocket.’ which is one of the standard functions of a browser, is used. For the interface for programming on this end point, similarly, the object group related to the ‘fetch()’ API of the browser standard is used to provide the mechanism for the program to be handled in the same mechanism as ‘FetchEvent’ of ‘ServiceWorker.’ Programs using the general-purpose reverse proxy mechanism only use the object provided by these browser standards.

Bunsanweb first downsizes the end point units that are reachable on the Web to units of programs that are individually run, not to units of clouds or services which manage multiple users. A program on a browser can serve as a server at the layer of Web programming, which is the base for constructing an end-to-end mechanism. This means that end points in bunsanweb will be desirably configurable programs, not servers or clients. For example, SDP data exchange for WebRTC connection is currently achieved through the signaling service focusing on SDP exchange in the center. However, this general-purpose reverse proxy mechanism enables WebRTC connections to be established without a specialized signaling service by directly posting OfferSDP to the URL indicating the end point on the Answer side.

A service on the Web is implemented as an intermediate exclusive for specific messages that are exchanged between users. The general-purpose proxy mechanism, in contrast, is a general-purpose intermediate program for messages that are exchanged between individuals. This mechanism is available for all messages and Web-based programs.

In bunsanweb, a general event stream, which is universal on the Web, for an event can exist on an endpoint. This universal event stream is called a “hashnet.” In a hashnet, a “Person” is handled as an endpoint where an event occurs. Event streams are exchanged between such endpoints. Inside each endpoint, it can be made possible to access an event treated as a universal event stream that occurs at any other endpoint.

Events handled here are Web documents that contain any content, and for each of such documents, a fixed URL is determined based on its content. To guarantee the identifiability of each content, the general information of an event, such as the issuer URL and date and time, and digital signatures and other items, is defined.

At an endpoint, this event is subscribed to from the event stream filtered based on the content of the event.

That is, the hashnet proposes a mechanism different from a typical event system, which issues and subscribes to an event for a fixed event queue. To achieve the mechanism, an event is defined in the hashnet to have contexts, as the mechanism that narrows down event streams based on the event content.

Each context is a character string, indicating the type of information and status of the content, determined on the assumption that it will be subscribed to by others. The “contexts” is the mechanism where a set of such contexts is embedded into an event, and events can be narrowed down by a set of contexts.

The event issuer embeds contexts based on the content of the event. The event subscribers process a variety of events picked up from the contexts.

For these issuers and subscribers, a set of contexts is handled as a virtual event queue. Note that such sets do not need to be the same between the issuer to whom the event is passed and the subscriber. This means that both the issuer and subscriber as “Persons” gain the ability to freely configure each event stream.

On the other hand, as is the case where timelines are handled in Web Services, event queues are specified fixedly on the Web, and this often causes dependence on a specific Web service that embraces targeted users. In such a case, the timeline of the Web service is expected, a program that registers and accesses an account is granted, and the program interprets this specific event format and then processes the target information. Specifying a specific Web service handled as a specific event queue, as mentioned above, is a significant reason why a person, as a user, depends on Web Services. In the end-point system that bunsanweb aims to establish, where “Persons” are independent, a departure from this dependency on a specific event queue is necessary. The hashnet enables each “Person” at an endpoint to optionally assume their virtual set of “Persons” through contexts, and then to interact with its virtual set in an event.

The hashnet is also a network among these endpoints, where a universal event stream is configured through coordination among independent endpoints. For individual endpoints without being linked with others, their regions of universality are each made up of only the events for themselves.The event queues at other endpoints are merged with own event queue, and a universal event stream is made available there. Dynamic changes on the hashnet, such as joining to an endpoint, are also presented with an event on the hashnet. To maintain the hashnet, an endpoint itself of the hashnet is also an endpoint application of universal events using this hashnet. Bunsanweb uses an architecture where the information on a “Person” is owned and managed by the person themself. In this architecture, an access privilege is assigned to individual functions, to process information collected to the ”Person.”.

Bunsanweb provides a program that integrates and maintains information on a “Person” and controls access to the program codes making up each function so that the function can treat the information as the identity of the “Person.” This program that can be treated as a “Person” is called the “dashboard.”

Unlike Web Services where the information of all the users is collected into a system for the functions to use the information, in bunsanweb, the functions of all the systems that use the information on a “Person” are collected to the “Person”, and then executed.

The dashboard provides a common URI space to each “Person,” like “localhost” that is used for a domain name. This URI space fora “Person” themself is called “me:” URI.

From the system’s point of view, the difference between each “Person” is the difference between the details of the data. Therefore, by using the common URI to the “Person” in the program code that handles data, the same code is implemented in the functions of the system that process “Person.”

In other words, the dashboard provides an information network structure that starts from “me:” URIs, each of which may have different content, and then expands to the hyperlinked information on the Web. The functions of a system display and update the information of each “Person” according to the information structure provided by the dashboard. An aggregation of such functions for “Person” makes up a system.

A system function is newly added from a spontaneous demand for for the information of a “Person” that has already existed. Also, when a system function is implemented, information added by the function causes demands of other functions to be made. Repeating this behavior makes the system evolve itself.

Bunsanweb uses this dashboard to manage the information for the mechanism that begins with establishment of the identity of a “Person” on the Web.

To make “Persons” accessible through a general reverse proxy, a permanent key-pair is necessary to present a permanent identity as a “Person.” Also, in a hashnet, this pair of keys is used as the identity of the issuer of an event issued from each system. That is, the information of a “Person” on a dashboard begins with storing the key-pair for presenting the identity on the hashnet.

The hashnet system then adds information (information necessary for the “event issuer,” etc.) to be used for the function group for expanding the information of a “Person.” While different systems in bunsanweb use such existing information, they introduce their own information to each system to expand the information of each “person.”

The programs that use the dashboard and hashnet are executed on the premise of permission to access the information of a “Person” treated as an identity. The programs issue to the hashnet an event with a digital signature signed using the identity.

Some of such programs may accept and process external information for executing part of systems, such as processing conventional account data.

As mentioned above, in bunsanweb, “programs” to access the information of “Person” need to be made portable. For each portable package, permissions for access to the information of “Persons” and their execution states are managed.

This portable unit for programs using the dashboard/hashnet is called “inst.” By executing this inst at a place where a “Person” exists, the information of the “Person” on the dashboard, the network of universal events on the hashnet, and arbiterary endpoints of the Web through the general reverse proxy are integrated.
Each inst serves as a function on the endpoint as a “Person”. An inst is categorized as a tool or command that processes the information of a “Person” within a dashboard. Each inst can be chained through an event via a hashnet and is enabled to access the Web by the general reverse proxy, which achieves loose coupling on the Web and flexible system configuration.

A system in bunsanweb is thought to consist of a combination of autonomous tools and commands, not as a monolithic integrated application, and has a structure whose configuration can be flexibly customized. The preferable policies here are combining a text editor and shell commands rather than using IDE, and adding bookmarklets or add-ons to the browser rather than using a dedicated client. In this context, text editors and browsers are the mix of front-ends of systems that differ from user to user. A network relationship is established among “Persons” using such text editors or browsers through these varieties of systems.

Bunsanweb aims for this kind of open relationship between systems through peers, inst, and networks.

And this is the relationship inherent on the Internet and the Web.