Bunsanweb currently views that the reason why the Web has expanded worldwide lies in the network itself, which enables its participants to freely conduct their activities through hyperlinks, using URLs where their permanent meanings are assigned.

Bunsanweb is designed to provide the architecture where freedom is achieved not only for hyperlinked documents, but for programmable networks as well. This is a challenge for achieving the World Wide Web of event streams that are currently “separated” by each specific event queue.

1. Prehistory of bunsanweb: Anatta Engine(s)

1.1 Finding a suitable programing archtecture for the web

Bunsanweb, however, did not focus on the network itself from the beginning. The project started viewing that the high loose coupling enabled free activities on the Web. This property has been brought about by the architecture called “REST (REpresentational State Transfer)” used for the Web.

In contrast, in the programming world, systems were still designed in the conventional way, which synchronously processed fixed data structures, even in the Web era.

The Web application “server” centrally processes data sets stored in RDBMS and then converts the processed data into Web pages. A browser is used as a “client” for accessing the server. This mechanism does not provide free relationship beyond the domain of the owner of documents that is enabled by hyperlink.

Considering the above, we thought that suitable architecture for the Web, as a base platform, was required for programs, and thus implemented native support for REST for programs themselves.

The environment designed for this programming architecture is called “Anatta Engine(s)”.

We thought that the browser-side mechanism that processes links, rather than the server-side structure that converts data, is the key for the strength of the Web. That is, the mission of the project is to enable the architecture to make the entire programming process take advantage of the capability of the browser that processes links.

1.2 For programs that enable hyperlinks

First of all, we enabled the Anatta Engine(s) to execute an HTML with the script tags as a program source, which was the case with the JavaScript environment for a browser equipped with the DOM and AJAX at that time.

For such an HTML/JavaScript program, the Anatta Engine(s) provides the back-end system that can flexibly place those programs to programmatically-fixed URI, and JavaScript APIs for the front end that enable link processing to be described without direct operation of the DOM structure, which is the model of the “Resource” abstracted as a container for hyperlinks. These environments enable users to write a program for loosely coupled processing of a Resource.

In these environments, the Anatta Engine(s) makes such a program itself, which enables loosely-coupled processing of a Resource, accessible as one of those Resources via hyperlink. That is, the Anatta Engine(s) serves as a loosely-coupled environment based on the Web for the programs, where Resources are basically accessed as the element of a system via the hyperlink without distinction between the server side and client side.

A system in such an environment starts with the AJAX processing using JavaScript on the browser from an action on the user’s browser, and links access one another to the Resources that are operating in parallel, and finally reach an asynchronous access via URL to a document storage of the primitive NoSQL type.

1.3 Making the concept of the dispersed social networking system

Next, for the Anatta Engine(s) environment as a system having the property of loose coupling, we brought in the idea of creating a social networking system that handles a network structure between participants.

This idea raises the issue of how a loosely-coupled social networking system can be dispersedly configured. From the viewpoint for the Web, dividing by functionality based on a single, central database is not an option.

A “state” including individual link navigation exists in the browsers of individuals at the primary level. The data of activities on a social network are generated from an individual’s respective “state” and then uploaded to a server for central management, from which the data are distributed to the concerned parties.

Based on the above, we determined to proceed with the system design for making dispersion occur on an individual basis. The system establishes social networking where individual data are managed on an individual basis and individuals get only their necessary information from other individuals through a program executed for their own data in their own device.

In this system design, the programs that serve as the functionalities of the social networking system are written in the same way as the processing of the data of abstract “individuals.” Starting from an “individual,” the system uses the link structure of a URI where the meaning of the relationship between links is fixed and the result varies depending on the information beyond the URI. Therefore, decentralization of a social network on an individual basis requires, as a Resource on the Web, standardization for programs that enables links to be followed starting from “individuals.”

1.4 Necessity of universal event stream

In this social network system dispersed on an individual basis, the event data processed by programs in the Anatta Engine(s) that are operated as a system are equivalent to the activity data of individuals that are able to be processed by application programs on a social network.

In a social network, activity streams, which are timelines handled by individuals, are aggregated in a list that includes the activities of other individuals based on the explicitly associated primary and secondary relationships. Applications on a social network are processed in the range of the activities obtained from these limited relationships.

On the other hand, individuals wish for functions for serendipity using information from activities other than those having a specified relationship. These demands are for a global timeline independent of the relationship that individuals have. This can be considered as the model of a network where all the individuals on a social network are (mechanically) associated separately from the ‘follow’ relationship.

Generally, program processing can be considered as converting all the data or narrowed-down results under some conditions. Program processing, therefore, requires the concept that universal activity streams are able to be always handled.

From the viewpoint of universal streams, individual streams are the streams filtered to activity streams including their actors in the individual’s follower relationship.

The current social networking services seek this universality and thus select specific services that meet it. As a result, we can view that the state before the Web has returned, which is the relationship where individuals depend on specific services.

2. Open network by universal event stream

2.1 “dashboard”, “inst”, and “site” that self-administers personal data

In the design of a social network that self-administers personal data using the Anatta Engine(s), we first came up with the following model: A social network is configured in such a way that individuals manage their “own data” in each localhost, process their personal data to those that can be made public through the Web and share the data with others, and also access others related to their individuals.

“Persons” on a social network primarily run programs that locally manage personal data and a variety of other programs that update personal data through local internal processing, and generate sharable data that can be accessed via the Web.

The program for managing this personal data is called the “dashboard.” The package system for programs that perform internal processing on the dashboard is called “inst.” The Web server that mirrors the sharable part of the data in the dashboard on the cloud is called the “site.”

The primary personal data are the profile of the person, which is the set of attribute values of the person, such as the name, organization, and preferences. These data are shared based on the relationship on the social network, such as relationships with friends, which, in turn, are customized to desired data.

In this mechanism mentioned above, the “activities” making up a personal timeline are also part of the personal data. The timeline, which is the list of activities, is the information to be shared through the “site.” An individual obtains activities on the timeline shared by others through relationships with friends or followers, and then runs the program that merges the activities into his or her own timeline.

2.2 Universal event network, “hashnet”

Activities on a timeline as a social network are the array of messages interpreted by humans, but part of them can be made to be automatically processed by a “bot” program. This bot processing was performed using the “inst,” as is the case with the profile processing. However, for a bot, an activity that the bot itself responds to is an event itself for the program.

Therefore, the dispersing mechanism of the timeline as a social network was separated from the dashboard, and was newly designed as a system for the universal event stream of the Resource programs in the Anatta Engine(s) level. This is the start of the universal event network, which is now called “hashnet.”

2.3 Universal event stream: From person to “peer” basis

The design mentioned above is considered on a “Person” basis; however, on the hashnet, an event issuer is one that issues events throughout a program including things like bots, and the unit centered on this issuer on the Internet is defined as a “peer.” The underlying mechanism of the hashnet is that these peers autonomously share their own event lists and pull the shared events amongst one another.

While the issuer of an activity was the first concern for a timeline of a social network, the content to process is most focused on by a program handling an event. This means that filtering events by the kind of content rather than the unit of the issuer is a favorable event stream.

The above-mentioned is a model that assumes a single event stream that can be universally handled across the world, and then uses part of the stream filtered by content. Because an event made by a “Person” is issued to this single universal event stream, no event channel of an issuer is specified. (In the case of trivial model, event channels must be specified for issuing events).

In this model, delays or losses occur corresponding to the range of targets in a universal event stream. But narrowing down the target range by content reduces such delays or losses. The reaching order of events may not match the order of occurrence of the events. However, when an event itself is made to have the link to the “previous event” in its content, partial ordering is possible by specifying the order relation of event issuers.

2.4 Universal event stream: Introduction of “contexts”

When a program code is written, the type of data to be processed is focused on, that is, a program specifies the types of data for events. In a universal event stream, events processed by programs are likely to be filtered by these data type.

Considering the above, it was assumed that multiple data groups are incorporated as the content of events, and thus the information structure to clarify such data groups was introduced in the structure of events. This information is called “contexts.” An event has “contexts” embedded as a set of tags. Information corresponding to each context exists in the content of an event.

The contexts are also used in a hashnet system. It can be said that an event stream first exists in a local peer, and as a result of its subscription processing, a program runs so that events are shared. For example, when the owner of a peer issues such an event as “F followed a peer” to add a new peer to the network, the followed peer itself receives the event “Followed a peer,” and then the added peer is verified, and subscription and merge processing are also performed. Then, when this “Followed a peer” event is further shared with another peer, peers on the network follow the peer.

This behavior occurs because the hashnet consists of a single peer as a system, and it expands to a network when these functionalities based on the event processing are added to the peer. When a mechanism as networking is added, an event for it is first defined, and then a program that interprets the event is implemented to act on the peer of the hashnet.

For example, we designed the mechanism of the “Request for participation from a new peer,” like an invitation, so that the processing of “Following a peer” by an existing peer is achieved by the issuance of an event that includes the necessary information and its verification processing.

2.5 Follow strategy at each peer

A single peer repeats the following operations: follows another peer, subscribes to its event stream, and merges the event stream into its own event stream. A peer list is configured with followed peers, and the subscription frequency is set for each peer in the peer list, and then actual network accesses are made according to these peer frequencies. The total of this subscription frequencies has the upper limit, and setting the subscription frequency for each peer based on this upper limit is called the follow strategy.

We have developed more than one follow strategies for subscription at peers. The first strategy is the extension of the follower subscription on a social network. This strategy aims to increase the number of events related to the contexts by obtaining distances to other peers based on the contexts, and creating a system of neighborhood clusters for nearby peers to follow each other

However, program processing needs to handle not only large numbers of events of similar types, but a variety of types of events as well. For this reason, we determined to adopt also the strategy for broad subscription by using the distance of the peer ID based on the public key for signature. This is similar to the handling of the distance in Kademlia of DHT.

The former assumes an application program (bot), and the latter assumes a system program. The latter is meant to communicate broadly, for example, updates or other changes on the program of the hashnet.

The prototype of the hashnet has been simulated and implemented under this design.

2.6 Over the separations of event queues

As is the case where the Web enables documents to be assigned to a single URI space and be freely linked across servers, the universal event stream model of the hashnet is designed to handle events across event queues, which are currently separated from each other, by assigning events to a space and then handling the events as an event stream in any extracted part of the space.

This model does not require the relation assumed by the subscriber of an event to depend on the relation assumed by the issuer of the event. One of the objectives of the hashnet is to openly obtain relations by entering the event stream when the contexts specified by the issuer are included in part of the contexts selected by the subscriber.

A peer may be able to encounter a new peer or other new contexts by, for example, processing subscriptions with contexts having open meaning.

2.7 First step toward expansive reconfiguration: Introduction of general reverse proxy

We are now dissolving the elements making up the architecture integrated, at first, as the Anatta Engine(s) into element technologies that can be achieved through Web technologies already incorporated into the most modern browsers, and are re-configuring such elements so that they can be used in multiple stages as the technical bases for making up the central concept–hashnet.

The first step of the approach above is using the “general reverse proxy” mechanism. This mechanism enables Web access to desired JavaScript programs including scripts that run on the browser on the machine within the firewall, through “general reverse proxy” in the cloud without any preliminary procedures such as account registration. This mechanism makes the “programs handled as Resource” in the Anatta Engine(s) available in more varieties and wider areas. The mechanism does not provide its unique API structure, and thus, users can use programs in the same way as using the standardized ServiceWorker API.

Peers were at first designed to work with the dedicated system “site” mentioned above that was mirrored in the cloud to make accessible the information on the locally-run program “dashboard.” However, the general reverse proxy made unnecessary such dedicated intermediary nodes for individual systems and enabled direct access from the Web to peers. Not only this example, but many systems currently using dedicated functions for Web Services in intermediary nodes in the cloud are expected to transit to end-to-end systems by using such general-purpose intermediaries. Also, the hashnet itself may serve as a general-purpose intermediary for events to make end-to-end links.

What makes the above possible is the advancement of Web technology. ServiceWorker and WebSocket, used to achieve the “general reverse proxy,” are standardized Web technologies. Unfortunately, these technologies may often be used to enhance dependency relations in Web Services. However, bunsanweb aims to expand the possibility of an open network with future potential advancement in Web technology.