RWW Notes & Info
General Notes
There are a few changes, notably the authentication methods and in-turn other components that furnish an ability to provide a more secure environment. The most important of the qualities that are sought to be engendered is the ability to ensure functional capacities that support the notion of freedom of thought. Therefore / therein, the functional outcome renders a means where the core AI services needed to be entitled to communicate as a human being; are private, yet the means to support this notion also leads to the requirement to support various safety protocols which in-turn depend upon the use of various AI related sub-systems. The objective is to ensure that they function internally, and in-turn that they are able to be used to support the notion of freedom of thought. The notion of freedom of thought is considered to be a fundamental human right, and as such, the Webizen systems are designed to support this notion.
Nonetheless; when quads and binaries transit from a persons private 'thought store' then within their community; followed by transmission to a curator (webizen alliance host provider); then that provider has a responsibility to ensure they're not facilitating crime, wrong-doings, harms - stuff that goes against the safety protocols; which is in-effect, a two-way street, the webizen host provider systems also protect the webizen owners from attacks; as such, these systems seek to provide another level of protection as is otherwise described as - safety protocols. . .
These systems act to protect webizen owners from attacks, and in-turn also protect the webizen host providers from facilitating crime, wrong-doings, harms - stuff that goes against the safety protocols. In-effect, these considerations are made in a manner that provides greater - permissive - transparency, about the sorts of things that can be done anyhow. This in-turn seeks to better support rule of law, by ensuring persons subject to law can take their grievances / problems, to a court of law to have them sorted out if they're unable to resolve them with the other party. This is in-turn considered to be a more effective means of ensuring that the rule of law is upheld, and that the rule of law is able to be upheld in a manner that is able to be understood by all persons. The notion of rule of law is considered to be a fundamental human right, and as such, the Webizen systems are designed to support this notion as part of its core functionality as does in-turn relate to the values credentials that are required to be held by the Webizen Host Provider.
Once human activity that thereafter leads to a communications event relating to other agents, it is thereby associated with express permissions, that are defined using ontologies and cryptographic instruments. These systems become part of the permissive commons ecosystems, that are in-turn designed to restrict the use of quads and binaries to only those that are permitted to use them. The notion of permissive commons is support fundamental human rights.
The Webizen Systems are not centrally controlled via any form of information system or global protocol; at least, to the maximum extent possible (all systems use Internet Protocol and DNS for instance - so there are some commonalities); and in-turn, the Webizen hosts are expected to operate independently but also in a manner that is able to be coordinated with other Webizen hosts. The Webizen systems are designed to be able to be used to support the notion of freedom of thought, and in-turn also to support the notion of rule of law - which is defined jurisdictionally, and in-turn supported via the permissive commons ecosystems, which in-turn seek to render assistance for forming AI solutions that can address differences between jurisdictions.
The apps are in-turn designed to function locally, in a manner that is somewhat similar to the early RWW Apps.
This note and related libraries are intended to provide support for learning about the related art that has been made by others historically, and in-turn how some of the concepts that were previously made are being employed in different ways in the new Webizen works.
Whilst there are various 'safety protocols' this should not be interpreted as meaning that the Webizen systems are designed to support 'big brother' or 'pervasive surveillance' or digital slavery or usury or many of the other sorts of social attack vectors that these ecosystems are designed to protect against. The Webizen Systems seek to ensure that persons are to the best of our ability able to be kept safe from acts of violence and wrong-doing; this is intended to also apply to any person who may hold a position of authority both within the Webizen systems and in connection to its use. The desire is to seek to ensure any lawful demands for inspection and/or use without the express consent of the owner, is subject to an audit-trail that may in-turn be presented in a court of law; sadly, even people who have enormously important jobs in society, may, whilst doing those jobs, break the law and make a mockery of the legal entity whom they are duty bound to represent. The Webizen systems are designed to support the notion of rule of law and other notions that are considered to be a lawful deliberations relating to societal behaviours between persons regardless of what job they may have; which in-turn is rendered assistance via AI solutions that can address issues that emerge from various types of actors and their tools (ie: other AI systems, etc.).
WebizenClient & Host WIP
Both the Webizen Client and Host systems have similar components. The End goal of the Webizen Client, is that it is installed on the end-user device that is being used; and incorporates web-server functionality. But this is in-turn also able to federate both private quads / information as well as permissive commons / shared quads (information) with other clients and in-turn also the host; noting that there is of course some information that is specific to the device, and users can also elect to ensure specified information is not shared to other devices; but both systems are essentially constituent parts of the users / Webizen owners environment.
Whilst the broad intention is for the majority of the webizen owners information to be stored on their own device(s); there are also practical requirements that necessitate the need for some information to be stored on a webizen host either or both locally (ie: a personal webizen server plugged into their router that's always on) and/or also on a remote webizen host, that is better equipped to support connections with other users who are in-turn using that information from the remote (ie: datacentre based) location.
These systems are also enhanced via the permissive commons ecosystem; which is intended to have the effect of being able to permissively distribute (thereby also - control) information that is permissively shared with others; this is intended to have the effect of the network acting like a CDN (content distribution network) that is distributing information to users who have the authority to view / use the information; who then in-turn become sources for others who have the right to access the information to obtain that information from them and other peers. These systems also require support for currencies; the currencies methods need to support the means to define both the biosphere (ie: energy) and socio-sphere (ie: economic) costs associated with the management and distribution of permissively available resources. These systems also need to retain a functional capacity to ensure the owner of the information is able to control the information and the means to ensure that the information is not used in a way that is contrary to the wishes of the owner of the information. Although this is considered a complex and therefore separate topic.
The main purpose of this note is to provide some information about the older RWW servers and in-turn also some of the older RWW and/or 'solid' apps; which are provided as a reference for developers to gain an understanding of how the RWW / Solid like systems work; and threby also, more usefully provide some information about the differences that are sought to be applied via the Webizen works.
RWW - Reference Web Servers
This folder contains older versions of RWW that are being used as a reference for the new libraries / app platform for Webizen. The reference implementations of RWW are in the following folders:
Gold
Helix (the dependencies are in the dependencies folder)
Helix Echo: is located: https://github.com/deiu/helix-echo
rwwapps: is located: in the rwwapps folder. A readme file is located (./rwwapps/README.md) containing some information about the rwwapps apps and in-turn also some information about the differences that are sought to be applied via the Webizen works.
There are other earlier implementations of RWW and related libraries that are not included in this repository. These are located in the following repositories:
- https://github.com/MyProfile/ (PHP)
- https://github.com/melvincarvalho/libAuthentication (PHP Authentication Library)
- https://github.com/openlink/virtuoso-opensource Virtuoso. It must be noted that this is by far the most sophisticated solution that has existed from before the beginning and continues to provide RWW/Solid leadership now, and likely into the future...
For the most-part, RWW has turned into Solid which progressively developed from November 2015 following a 1m gift from Mastercard. as noted here.
The more recent core libraries include;
More info is found: https://github.com/WebCivics/solid-stuff
There are an array of old 'bits and pieces' that are no longer online. Indeed the history relating to that problem led to the circumstance where I secured webizen.org for future purposes. There are many unsung heroes, it is hoped that this work will help to positively recognise some of them via dignified means. (not necessarily publicly).
There is also related works that were never employed. One of the biggest examples that i am mindful of is the work done on the concept of HTTPa which whilst not part of RWW in and of itself, was at least in my mind - considered to be 'related'...
RWW Servers: Implementations vs. differences
RWW had concept of an authentication server most-often being located elsewhere on the web, and the app would then go-to a file that sought to find that authentication end-point and then use it to authenticate the user. Whilst this was certainly not always the case, the practical reality has been that it had become the main way these systems were being designed / applied - to be made to function.
Whilst the works that I was in particular responsible for (which is different to what the others were working on, sometimes similar and supportive - but certainly not always); was about a 'knowledge banking' model that i'd been developing, that had earlier been conceived as a 'information bank'; therein, there was a provider that was thought necessary in ways that have differences to how I've updated the models following clear 'feedback' from jurisdictional leaders in the public and private sectors (generally those who had nothing to do with the former RWW works); that has comprehensively demonstrated that they do not seek to support human rights in any meaningful way, irrespective of any opportunity produced that provides a means for them to benefit greatly from the work that was done to enable their ability to benefit greatly by helping to implement it in a way that did so. Upsetting, but now therefore an accepted fact.
nonetheless, consequentially, there are a variety of legacy related 'views' and 'beliefs' that are espoused by others that relate to these older models; these should not be confused with the Webizen models, indeed there is some effort that is being applied to seek to ensure there are clear separations defined in the implementation between the different 'mind-spheres' as to seek to ensure Webizen users are then required to expressly make decisions to mix quads that relate to these different ecosystems.
Webizen, is an effort to provide an alternative that is now better able to be applied in a way that supports the values upon which the work was originally conceived to support; particularly given, the continued issue that provenance systems are not sufficiently supporting the means for persons to clearly and accessibly define who was involved in what, when, etc.
The Webizen work requires a means to disconnect users should there be cause to do so, as such a method is required to support backwards compatibility and/or the ability for users to be exported to systems like solid; and indeed also, to some-extent, interoperability, in-order to provide support for Webizen safety protocols and related requirements.
The Earlier Web Civics works also sought to break-down the authentication URI from https://mydatabox.providersdomain.tld/me# to provider: domain.tld username: myusername passcode: mypasscode and a check-box for 2nd factor auth. The demo is: http://dev.webcivics.org/
Earlier work (~2012/3) made a mock-up to show how the TLS certificates were intended to AUTH devices: http://mediaprophet.org/ux_KB/page4115294.html alongside an array of other related concepts noted therein.
Webizen Models
The Webizen models produce an environment where apps are authenticating against either a local server or a server that is located within a users own network. Webizen systems also have an authentication server that is located at the root of the users webizen network. The local authentication server is located at: https://localhost/auth which in-turn corresponds also to their domain-name / subdomain.
Additional Requirements
Networking
The networking requirements will include incorporating the Wireguard/tailscale client based library; and in-turn also, an advanced DNS library to support various IPv6 functions - as best as is able to be achieved.
These systems will also require the ability to employ TLS; and the TLS (cryptography) packages need to be harmonized.
The implementation as a host package; will have different requirements to the installation of the package for a client. It is therefore not entirely clear at the moment, whether its better / easier to develop two separate packages; or to develop a single package that can be configured to operate in either mode. The latter is likely to be the most efficient approach.
It is also hoped that the host implementation is able to be supported by a dedicated IPv6 Range; and that the networking is thereby performed within the network using IPv6 and related extensions, etc. This is not entirely clear at the moment, but it is hoped that this is possible.
DNS
There are a few different options with DNS but it fundamentally requires testing and evaluation. Advanced DNS is required to be able to support DNS-SEC and the Webizen-DNS related functions; it is unclear whether this is easily implemented within the tailscale based network, or whether it can only be implemented for public-facing systems between hosts.
Interfaces
There are presently an array of different interface components that have been produced by others that are being reviewed to identify what might be useful, and how the package should be produced to support the interfaces that are required, whilst harmonising the approach.
The interfaces that have been identified so far include:
- Tailscale host (headscale) UI
- Tailscale Linux Client UI (app)
- A Server Web Admin UI.
Local WebServer
The Caddy Webserver is written in go and an extension has already been developed to make it work with Tailscale. it is able to get the TLS certificates it requires from the Tailscale system; and is also able to provide support for hosting static sites in addition to being able to operate as a reverse proxy.
WebizenAgent
The webizen agent is considered to be the persons 'robot' that these systems are designed to support; and in-turn, the webizen agent is designed to support its human owner. in-time, other webizen agents are then defined also to support the needs of groups.
Safety Protocols.
In society, people do bad things. Most of the time the way this is sought to be handled online is via pervasive surveillance systems that whilst said to be required by government(s) also have the effect of leading to platform solutions that act to share information with commercial entities in various places around the world; who do not necessarily have the best interests of the people in mind. This is a problem that is not unique to the web; but it is a problem that is particularly acute in the web / cyber environment.
Some ways people are attempting to address the implications of pervasive surveillance are via the production of encryption methodologies that are said to be 'privacy focused' yet, people do bad things; and the reality is that there are many ways that people can engage in behaviours that involve harm being caused to others; including but not limited to people being coerced into doing things that they would not otherwise do. A balance needed to be formed, as to protect human rights - which includes many attributes that should not be considered necessarily competitive, but rather complimentary. So, rather than enabling or empowering unfettered means for foreign agents to engage in pervasive surveillance related activities that may well act to undermine the rights of people; it is considered to be important to ensure that there are means for people to be able to protect themselves from harm, and that it is fundamentally the responsibility of one-another to ensure that this is the case. As such, the combination of the values credentials and in-turn the safety protocols are intended to be the means through which this is achieved.
The Webizen agent will need to be developed in such a way that it is able to support the functional requirements of the safety protocols. This is not to say that the safety protocols are necessarily the only means through which this is achieved; but it is to say that the safety protocols are the means through which this is achieved in the context of the Webizen. The safety protocols are intended to be the means through which people are able to protect one-another from harm, and declaratively define the terms expected of one-another when forming and maintaining relationships.
CogAI
CognativeAI is a relatively new technology that's still actively being developed. It fits into the broader semantic web ecosystem.
Escape Hatches
There is a concept of webizen users - in worst case senarios, potentially being banished to a 'webizen prison' - where they are unable to cause any further harms on the webizen network and are thereby subject to a review process which may in-turn lead to exile. This is considered to be a worst case scenario; and the hope is that the webizen systems are designed to provide a capacity for people to be able to leave the webizen environment and take their quads and convert it to a 'data format' required by an alternative platform that defines what they require in those terms.
This is important for a number of reasons; but the most important is that it is important to ensure that people are not locked into a system that is not able to provide the functionality that they require; Yet this is considered to be a different problem that will be better described elsewhere - for now; see https://datatransferproject.dev/ for more info.
Nonetheless; The hope is that whilst many protections are being asserted; the basic structure for quads is defined in a manner that can be exported to an alternative platform; for various reasons, but primarily to ensure that people are not locked into a system that they may not be able to leave without significant difficulty and/or very negative consequences other than those of their own making and or other circumstances that may relate to a court-order or similar.
Databases
The RWW servers used bolt, which has now been updated to use the bbolt library. Whilst the candidates are still being considered, the preference is to form at least three separate database dependencies; the first being for the users quad store; the second being for permissive commons, the third being something that's designed to function in-memory, for the purposes of caching. Additionally, consideration about how a vault may be best provided is also considered to be an important consideration, as are considerations about how logs should be managed; and whether they're effectively part of a database that is assigned to the webizen agent (as a 'robot' ;).
I must note; that I am strongly against the idea or concept that people are defined by some sort of 'wallet', nonetheless, there's some sort of vault function that needs to store credentials, private keys, etc. I think more broadly, the scope of what the vault is likely to contain is more than anyone has ever carried in their wallet(s).
Ontologies & core 'ai' functions
The core ai functions are intended to be provided by the WebizenAgent. The WebizenAgent is intended to be a 'local' agent that is installed on a device that is intended to be a local webizen host server. This host implementation is also intended to be the basis for producing the installable package that is installed on a device that is intended to be a local webizen host server. This is in-turn intended to support the installation of additional packages that will have a range of different types. Some may be trained AI models, others may be applications or services or other forms of extensions.
So, in summary, whilst the webizen agent itself is not intended to be a singular AI 'training model' or package that does everything; rather, that it is intended to be the core process that is able to be extended via additional packages that can be loaded into either or both; the device and/or the network; and/or via a federated community of webizen who pool their resources to provide support for a specified group of users who wouldn't otherwise be able to access software based tools that perform similar things in a similar way.... What is required within the webizen agent, is the means to provide the core tools needed to preserve 'freedom of thought', which is thought to at least include a vocabulary model and the systems that are required to support the safety protocols.
This core package / service - somewhat like an updated dictionary; is thereby intended to also support the core ontologies, and in-turn become the basis for the development of the core AI functions that are required to support the WebizenRWW. It is entirely likely that there will be more components that are required.
Core apps
A bunch of core apps are required; this is not unlike the experience people have with other operating systems, although the nature of how these things works is indeed very different.
The core apps are intended to provide the tools needed by the user to usefully employ the webizen environment. It is also desirable that developer tools are also provided, noting that the expectation is that the ability to produce apps should be relatively easy for people to do. Particularly, if they are able to use the tools that are provided to them and in-turn also AI agents that are increasingly demonstrating the ability of AI agents to both assist and teach people how to do things.
Webizen API
The webizen api extends based upon the functionality provided via Webizen software that's implemented and/or available to that system in a defined way.