The proposed information environment is a kind of decentralized social network. Unlike many existing solutions, this environment has a number of useful properties in addition to decentralization and is built on simple and standard technical solutions (email, json, text files, and a bit of blockchain). This allows anyone with basic programming knowledge to create their services for this environment.
Universal Identifier
In any online environment, user and object identifiers are one of the key elements of the system.
In this case, the user's identifier is the email, which has essentially become a widely accepted identifier for authentication on websites and other services (like jaber, openId).
In fact, the user's identifier in this online environment is the pair login+domain, which is conveniently recorded in a familiar format for most users. For greater decentralization, it is preferable for each user to have their own domain. This aligns with the principles of the indivweb, where a domain is used as the user identifier. In our case, the user adds a nickname to their domain, allowing them to create multiple accounts on one domain (for friends, for example) and making the addressing system more flexible.
This format of the user identifier is not tied to any network. If a user posts their data on the TOR network, they can use domains in the .onion zone; if it is a network with a DNS system based on blockchain, then domains like .bit can be used. As a result, the addressing format of users and their data does not depend on the network through which they are transmitted (the login+domain pair is used everywhere). For those wishing to use a bitcoin/ethereum address as an identifier, the system can be adapted for the use of pseudo email addresses like xaca1b7c8126806f672f9dbee4951527bb0f2c4e4@ethereum.blockchain
Addressing of Objects
This online environment is essentially a collection of objects that are described in a structured machine-readable format, reference other objects, and are tied to a specific user (email) or project/organization (domain).
Object identifiers use urn in the namespace urn:opendata. For example, a user profile has an address like this:
urn:opendata:profile:user@domain.comA user's comment has an address like this:
urn:opendata:comment:user@domain.com:08adbed93413782682fd25da77bd93c99dfd0548where 08adbed93413782682fd25da77bd93c99dfd0548 is a random sha-1 hash acting as the object id, and user@domain.com is the owner of this object.
The principle of publishing user data
With their own domain, a user can easily publish their data and content. Unlike Indiebeb, it does not require creating an HTML site with embedded semantic data.
For example, basic information about the user is placed in a datarobots.txt file, which is located at an address like
http://55334.ru/konstantin@55334.ru/datarobots.txtAnd has content in the following format:
Object: user
Services-Enabled: 55334.ru,newethnos.ru
Ethnos: newethnos
Delegate-Tokens: http://55334.ru/konstantin@55334.ru/delegete.txtIn other words, it is essentially a set of lines with data in key->value format, which can be parsed easily by anyone with basic programming knowledge. Additionally, the data can be edited as desired through a simple text editor.
More complex data (profile, comment, post, etc.) with its own urn is provided as a JSON object via a standard API (http://opendatahub.org/api_1.0?lang=ru), which can be located either on the user's domain or on an external site to which the user has delegated the storage, publication, and editing of their data (in the Services-Enabled line of the datarobots.txt file). More about such external services is discussed below.
Simple ontology and JSON
The ontology of the communication environment is relatively simple compared to the ontologies of industry knowledge bases. This is because there is a relatively small set of standard objects (post, comment, like, profile, review) with a relatively small set of properties.
Therefore, to describe objects in such an environment, it is sufficient to use JSON instead of the more complex structure and parsing of XML (it is important to remember the need for a low entry barrier and scalability).
To obtain an object with a known urn, it is necessary to contact the user's domain or external services to which the user has delegated management of their data.
In this online environment, each domain hosting an online service has its own datarobots.txt located at a URL such as example.com/datarobots.txt with similar content:
Object: service
Api: http://newethnos.ru/api
Api-Version: http://opendatahub.org/api_1.0From which we can learn that data about the object can be obtained from a URL such as:
The JSON object has the following structure:
{
"urn": "urn:opendata:profile:example@55334.ru",
"status": 1,
"message": "Ok",
"timestamp": 1596429631,
"service": "example.com",
"data": {
"name": "John",
"surname": "Gald",
"gender": "male",
"city": "Moscow",
"img": "http://domain.com/image.jpg",
"birthtime": 332467200,
"community_friends": {
"example1@domain.com": "1",
"example2@domain.com": "0.5",
"example3@domain.com": "0.7"
},
"interests_tags": "cars,cats,cinema",
"mental_cards": {
"no_alcohol@main": 8,
"data_accumulation@main": 8,
"open_data@main": 8
}
}
}Service Architecture
Third-party services are necessary to simplify the process of publishing and searching for data by end users.
One type of service mentioned above helps users publish their data online. There may be many similar services, each offering users a convenient interface for editing various types of data (forum, blog, Q&A, etc.). If a user does not trust third-party services, they can install a data service script on their domain or develop one themselves.
In addition to services that allow users to publish/edit data, there are other services in the online environment that perform relatively complex tasks that are quite challenging to implement on end-user nodes.
One type of such service is data hubs ( â for example), which serve as a kind of web archive that collects all publicly machine-readable user data and provides access to it via API.
The availability of services in such an open decentralized online environment significantly lowers the entry barrier for users, as there is no need to install and configure their own node. At the same time, the user retains control over their data (they can change the service that publishes their data at any time or create their own node).
If a user is not interested in owning their data and does not have their own domain or someone familiar with one, by default, their data is managed by opendatahub.org.
Who pays for all this?
Perhaps the main problem of almost all similar decentralized projects is the inability to monetize them at a level sufficient for stable development and support.
To cover development and marketing costs in this online environment, donations and tokens are used.
All donations that users contribute to internal projects/services are public, machine-readable, and linked to email. This allows them to be taken into account, for example, when calculating an intra-network social rating and publishing it on user pages. When donations cease to be anonymous, users are essentially not donating but 'chipping in' to support a shared informational environment, just like people chip in for the maintenance of common areas, with a corresponding attitude towards those who refuse to contribute.
In addition to donations, tokens issued in a limited quantity (400,000) are used to attract funds, which are awarded to everyone who contributes to the main fund (ethnogenesis).
Additional token functions
Each token is a 'key' to access this online environment. This means that one can only use the services and be part of the online environment if they have at least one token, which is linked to an email.
Tokens serve as a good spam filter due to their limited availability. The more users there are in the system, the harder it is to obtain a token, and the more costly it is to create bots.
People, their data, and social connections are more important than technology.
The described online environment is technically a relatively primitive solution. However, what is more important are not so much the technologies as the people and the social connections and data (content) created within the environment.
The created social community, whose members have their universal identifiers (email and their domain) and structured data (with URN addresses, ontology, and JSON objects), can transfer all this data to another online environment when a better technical solution arises, while preserving the established connections (ratings, evaluations) and content.
This post describes one of the elements of a network self-organized community, which, in addition to a decentralized online environment, includes several offline directions that enhance the benefits of the online environment and serve as 'clients' that largely determine its functionality. But these are topics for other articles not directly related to IT and technology.
Source: habr.com
