What is Web 4 🗳

Web 4 is a set of four modular paradigms (time tokens, provable personhood, information entropy, and geosocial systems) that allow integration of provable democracy in any social system that seeks to be more collaborative (organization, government, community, etc.). Modularity allows any project to adopt one or more of these principles to increase the accuracy, fairness, and transparency of each individual's role in collaboration. Furthermore, web 4 is designed to be biomimetic, defined as reflecting natural cycles and systems.

Web 4 is built on top of web 3 (it's blockchain-based) while being fundamentally different and providing enough benefit to society warrant the new title of web 4.

In essence, web 4 is guide for building consensus tools that helps to manifest a shared desire, opinion, or solution by providing a fair system of accounting using time-limited votes, real people, and existing geopolitical stratification.

Web 4 combines real-world components like time and geography with existing blockchain technology.

In this manifesto, I will define each of the components of web 4, provide psudeocode to illustrate the minimum integration into web 2/3, introduce the benefits to society, and offer a roadmap to adopting these concepts.

The Problem

Democracy, society's biggest and most successful consensus and collaboration mechanism, has become inefficient, inaccurate and too slow to keep up with the modern world. Groups of people organizing, whether to turn a profit as a company, or to live together in a community, are often under-, mis-, or not represented at all in the decision making processes that affect their lives and work. In both governments and companies it is the few that make the decisions for the many, even with the illusion of "having a say" that exists in a representative system.

The Solution

By providing each individual with equal power in a transparent decision making process, the true intent of the majority can not only be known, it can be acted upon in predetermined ways through smart contracts. Though this solution seems simple, there are issues that will need to be addressed according to the needs of each group of collaborating people, such as ensuring one person per account, tying tokens with time, accounting for times when some collaborators have more influence than others based on defined actions and roles, as well as protecting the privacy of decision makers where appropriate. This paper will detail these solutions, and recommend that each system decide what components of web 4 to use or not use. For example, systems can (and should) be built using time tokens that do not use biometric data at all, a common concern in our modern world.

Background

Before we detail web 4, we must look briefly at the concepts of web 1, web 2, and web 3.

• Web 1
  Static web. Files are served from a remote server to a user's browser.

• Web 2
  Dynamic web. Web pages take a user's information and desires into account to build a unique experience for them. Asynchronous requests allow single page applications to thrive. Applications are still served from a central server.

• Web 3
  Decentralized web. Applications, often open-source, exist in distributed networks instead of a central server. This unfederated model trades control and censorship for freedom and autonomy.

• Web 4
  Biomimetic web. Time-limited tokens are given to each individual, and used as a measure of opinion or desire in collaborative systems exhibiting a biomimetic, or fractal, architecture. (Alternatively called Time Web or Democratic Web)

Today, the top 100 websites/apps by traffic are all web 2-based. The web 2 paradigm fits closely with the wider environment of corporate-owned information.

As more and more individuals and societies are reconsidering the place of government, censorship, centralization and federated power, web 3 has emerged as a powerful, provable option to shape the evolution of information and society on planet Earth.

A growing portion of web 2 websites and applications today have elements of web 3, like cryptoblogs and games. While web 2 and web 3 can operate independently. Web 3 apps can be completely on-chain, or integrated into any web 2 website (ie. tokenization) to access web 3 features. Similarly, web 3 and web 4 can operate independently, but it makes the most sense for web 4 to be built on blockchains (web 3) to gain the benefits of reliability and transparency.

Guiding Philosophy

Web 4 seeks to implement biomimetic systems in harmony with the universe itself by replicating nature: the abundance of the Sun, rising entropy, and the similarity + uniqueness of each human being.

Web 4 tests the hypothesis that when we create information systems in harmonic resonance with natural systems, our society will be able to advance more rapidly than ever before, as we will be able to synchronize energetically with the larger systems of bioelectromagnetic information processing around us (the Earth, Sun, and Galactic core).

Web 4 catalyzes free will by empowering collective decision making to manifest common goals and desires. Web4 strive to make systems that are public, provable, and powerful. These systems find use in curation, community, and consensus.

Defining Web 4

Web 4 introduces four modular components for provably democratic systems, suggested to be built on top of web 3's open-source decentralized networks.

There are four conceptual underpinnings (modules) of web 4

1. Time Tokens Individuals may claim time-limited tokens at given intervals, which represent that interval and the recipient themselves. Only one time token can represent a given interval and individual. Time tokens have functionality to the original recipient only.
2. Proof of Individuality (One Person, One Account) Biometric Secrets, Social Verification, Proof of Liveness, white lists, etc. are used to guarantee no individual can collect two time tokens for a given interval by holding two accounts.
3. Information Entropy Information degradation over time, increasing cost to call smart contracts over time, and other mechanisms replicating entropy ensure that a system stays malleable, enabling a greater degree of biomimicry and systemic evolution.
4. Geosocial Systems Fair (according to each system's specific metrics) and transparent collaboration through accounting the opinions and desires of participants in geographic bounds which may be defined by geopolitical tradition, or voluntary declaration.

Each module can be implemented separately or in tandem. This paper invites you to involve any of these ideas into your current or future projects. We will discuss these concepts one at a time, but first let's examine why we need them in the first place.

Why we must grow from web 3 to evolve democracy, society and consciousness

Provable democracy cannot be fully achieved in web 3 as-is because there is no inherit limit over how many accounts a user may control.

Democracy is essentially reaching a consensus with the idea that each person is equal in their influence on that consensus within defined bounds.

Many different consensus models have been developed in web 3, most notably, proof of work (POW), proof of stake (POS), and delegated proof of stake (DPOS). These paradigms of consensus are used primarily to determine which chain of transaction records (blocks) is considered valid, "securing" a blockchain.

POS and DPOS are additionally used in projects like Hive to allow users to "vote" on valuable content. DPOS is also used for networks to determine who can access network resources, such as in EOSIO blockchains.

However, both of these POS/DPOS use cases (curation and resource allocation) are not democratic in the sense that each account is not equal. In both cases, the root of democracy is in the token, not the individual, and the ownership of tokens determines the voting power or computing power held by an individual.

In the end, the only way to implement true democracy in any system is through giving each individual equal power. The only way to do this while keeping web 3's decentralized nature is to implement the technological and idealogical advancements needed for a one individual, one account system. These advancements needed for provable high-fidelity democracy are, for simplicity and communication, called web 4. These principles aren't intended to be used for block production consensus, but for

Finally, there are many times that we don't want each person to be granted equal power in a democratic system simply for being born a human in a place. Merit-based (requires certification), choice-based (chosen by members of the system) or action-based (pre-vote action like education) requirements may be implemented in smart contracts as long as that action or merit is represented in data objects, such as the badge system in Hypha DHO. High-fidelity democracy (many integer-voting units per person's vote) can give an individual fractional or multiplied influence in a transparent way by using whole numbers as a multiplier of a set, system-wide voting power defined as the granted influence on consensus every voting member is given.

Let's review web 4 concepts one by one.

1

Time-issued cryptocurrency (Time Tokens)

Time tokens may be offered or directly distributed to users' wallets periodically. They work by hashing a unique personal identifier (address) with a time identifier, linking each token to a person and a span of time. This information can be stored on the token, like a non- or semi-fungible token, or be metadata that is later compiled by the system by reading a tx memo or other transaction history of the wallet/account.

The Gears of Time Tokens

Time tokens rely on the following concepts:

1. Time Tokens
   Individuals may claim time-limited tokens at given intervals, which represent that interval and themselves. Only one time token can exist with one interval and wallets, and one individual can't hold another's time tokens.
   These tokens provide the user with a function or action. The action burns the token, which may cause some change in the state of a system, such as minting another token, registering a vote, or any other action. Thus, each time token is unique yet semi-fungible. Time tokens can also be checked for freshness when needed, for example a user may have to use a certain time period's token to cast a vote in an election, which should also exclude that particular time token from all other election.

2. Time Unit
   A time unit is a time interval that is a sub- or superset of a timestamp. This means that a time unit is some amount (or fraction) of seconds. Each time token MUST be the only one in existence stamped with a particular time unit and account/wallet (requires both).

3. Time Faucet
   A time faucet is a smart contract that offers any qualified account EXACTLY one time token per unit of time passed since their last faucet. This can be an active faucet; requiring some action by the recipient, or a passive faucet; automatically sending the cryptocurrency to the user.

4. Qualified Accounts
   Qualified accounts adhere to the individuality requirements of a given system. Each web 4 system will do this differently according to their needs, perhaps with a whitelist, social verification, biometric verification, proof of liveness, or other means.

How do Time Tokens work?

Time tokens operate like non-fungible tokens in their structure, storing a time unit (integer) with a unique user identifier (string) as the payload data.

The user's identifier may also be linked to a biokey discussed in the next section.

Time tokens are platform-independent, and need only the ability to store or imply simple data: a time unit and a user identifier.

In practice, a time unit is an integer that counts up the number of pre-defined time spans that have passed since an epoch. The epoch is typically when the system went live, and represents the first time unit.

Provable Democracy with Time Tokens

If we were to create a time token for a US citizen to vote in the US presidential election, the time span would be 126144000 seconds (four years), and the epoch would be at a timestamp representing the start of the election day previous to the first election to use time tokens. On election day, an active faucet would send/offer one time token to each registered voter (requires module 2: provable individuality) with a payload of the user's unique identifier and the integer 1 as the time unit (the next election would be 2, and so on.) The user would then send the token to the election's smart contract address with a memo of their vote. The system would check the identity of the voter as the one the token was minted to, validity of the memo, and the time unit against their list to ensure they are voting in the correct election, then burn the token (or else reverse the transaction if malformed), and send the user back another token representing a "I Voted" sticker.

This example intentionally doesn't account for anonymity

This example is simply implementing an existing system. It becomes beneficial when we realize that we can just as easily send the person 12 voting tokens so they can vote on their first, second and third choice. It becomes even more interesting when we send tokens every month (or so) and allow the people to vote directly on the bills that are being presented to their respective legislative bodies, just for fun, equivalent to a poll. It becomes even more expansive when we have the faucet smart contract require educational actions, such as opening a link to information on these bills (summary and the full text) to receive their votable time tokens.

It seems that the only way to beat misinformation is with information. By enforcing the integrity of voter informedness according to known metrics, a solution may be developed where opinion can be trusted to be at least well-representative of the population's desires.

A Simple Example in web 2

Here is the minimum information stored in a time token, using JSON Web Token (JWT) as an example

{
  "header": {
    "typ": "JWT",
    "alg": "HS256"
  },
  "payoadData": {
    "time-unit": 294957,
    "userid": "7f3e873a2c3d"
  }
}

Below is a brief pseudocode example of how one could use a signed time token as a JWT.

See Appendix A for more detailed pseudocode of a time token.

const passedBioData = {..} // biodata from user

const header = {
        "typ": "JWT",
        "alg": "HS256"
      }

const payloadData = {
    "time-unit": "294957", 
    "userid": "7f3e873a2c3d", 
    "appData": {
        "gold": 479,
        "honey": 23,
        "axe": 0 
    }
}

const bioKey = bioKeyGenerator(passedBioData); // Biometric provider's key or one generated direcly by user

// --- Here we have the signature, to be used for any purpose --- \\
signature = HMACSHA256(
    base64UrlEncode(header) + "."+
    base64UrlEncode(payloadData), 
    bioKey
)


function bioKeyGenerator(bioData){
    // Function takes data in the form of user input into their browser or smartphone.
    // Data is normalized (explained in Appendix A, not shown here)
    bioKeyChecked = bioData;
    // Return biokey 
    return sha256(bioKeyChecked)
}

The notable parts here are the time-unit and userid in the payload, and the biokey which is generated by a user's biometric data.

We have said web 4 is based on web 3 (blockchain), but this example intentionally used web 2 technology. Much of the rest of this paper goes over ways to avoid trust by incorporating biometric data in a specific way, but that's not always needed, or helpful. We have to trust a government to run our elections. We trust social media platforms with our photos. We trust the Sun will rise, and a giant meteor won't crash into Earth.

The truth is, all systems have some level of trust, even if that's just in the system itself. If we try to get rid of this trust by implementing a system so good we are our own private key, it can backfire, and when it does, if we built it because we were fearful instead of trusting, that's super lame.

While I'm going to lay out a possible solution to use biometrics in a "trustless" way that fits with web 3 ideals, personally I think it's a bad idea in general, and I won't be designing my Web 4 apps with it for quite some time, if ever, because I think social verification is more trustworthy for all stakeholders.

Are Time Tokens needed?

For a minimal system, there is no need for a token to track time. Any stored time point can be calculated in real time to determine the user's weight in curation or consensus forming. Any on-chain datastore would do, and there's even possibilities for manual input through photo-hashing pictures of a user's inked response on a printed paper.

2

Proof of Individuality - Biokeys, Biosecrets, + Social Verification

Please Note: This paper originally only spoke of biokeys and has been expanded to include social verification. There are solutions available today (like FaceTec and BrightID) that solve the same issues presented here. This paper seeks to outline a web 3-based system (decentralized + open source) that can run without a centralized actor, while not providing specifics to accomplish these goals. This is more of a thought experiment than a suggestion or requirement.

Biometric secrets (biosecrets) are akin to any cryptographic private key, but they are your actual biological data, or, more specifically, a four dimensional expression of your humanness from which biometric data is collected. The difference between a biosecret and a fingerprint or retinal scan is a biosecret involves a short expression (movement and/or sound) AND a physical attribute, not just one.

Instead of a private key generated alongside a public key, a hash of quantized biometric data becomes your public key, which is paired with your actual flesh-and-blood-and-sound-and-movement-data, your private/secret key, or as we call it "biosecret" which isn't stored on any server or blockchain.

Keys

1. Biometric Key: Digital identity keys generated static assessments of an individual's physical characteristics. (Fingerprint, Iris, Facial recognition)

2. Biokinetic Key: Digital Identity keys generated is a specific biometric expression measured over time via movement. (Voice Recognition)

3. Biokey: Any type of private key generated by an individual's measurable characteristics or expression. (Includes Biokinetic and Biometric)

How this can go wrong

In today's biometric space, static images are most commonly used for things like fingerprint and facial recognition, and geometry is the means to compare this data. Biometric secrets generated from static images are not secure, as static images can be faked. [2] Video offers a better solution to this problem, as it is harder to fake, can include audio, and lets developers create a whole new set of algorithms based on a changing stream of data. Facetec is one company using video for biometric verification.

What could be used to generate a biokey?

This stream of data (video + audio biometric expression) could be a user doing a series of hand gestures, singing a part of a song, speaking a phrase, speaking a phrase in different voices, clapping, making a series of facial expressions or movements, or anything else one can imagine.

For security, biometric expressions (used to make a biokey) must be unique (for example, which combination of words to speak) and many types must be available (gestures, movement, singing, clapping, etc) and used in combination. If each person's biokey was generated from the same single biometric expression, it would be a matter of time before specific AI could be developed to deepfake it for anyone. If the user is the only one that knows their biometric expressions it becomes nearly impossible to guess the type and nature of the expression, and even if that is known, difficult to use the same technique on more than one account. It also means this expresion can be forgotten, making accounts not recoverable. The nature of the uniqueness could be chosen by the user, or generated at random from the biokey software which would prompt the user to complete an action in a specific way.

With a wallet storing your encrypted key, you will only need to preform your biosecret in the event of adding to a new wallet or in case of account recovery. There is also the option to create a hybrid system where a normal private key is generated in tandem with a *recovery *, used only in the event of a compromised account, similar to the Mandel (formerly EOSIO) software.

Why do we need this, again?

Democratic systems certainly are being built without biometric verification, and will continue to be even after suitable biometric technology develops along the open source, client-side requirements. For now, decentralized solutions like Civic, and centralized tech like Facetec provide the necessary individuality at the cost of trust and requirement of citizenship. Additionally, biometric data can be avoided entirely by using a social verification platform like BrightID or piggybacking a community like Eden on EOS that has a list of socially verified accounts on-chain. As different projects implement web 4 in their own ways, the ideas presented thus far will develop as flaws are found. And there's always the ability to use a whitelist, the most low-tech, high-trust, and simplest solution.

Integrations

Solutions exist to allow any developer to prompt for a fingerprint scan or facial scan, even from the browser. [4] This makes integration of an already-accepted biokey type on a cellphone into any web3 application feasible.

Trust Issues

The biggest issue with biometrics is the lack of trust the general population has (or should have) with giving up their biometric data, including the growing number of facial recognition softwares and databases. The lack of trust is almost always associated with an individual's lack of clear consent, and lack of understanding the technology itself.

To alleviate the trust issue, biokey generators must be:

1) open-source
2) entirely run on the individual's hardware (client-side), and
3) not expose any biometric data to any other users or to a web 4 system itself (the biosecret is never stored or transmitted in any way).

There will always be security concerns with biometrics. For example, if a user uses their biometric secret to unlock their mobile device, another app could be secretly recording the camera in the background. A person could record them doing their secret, and try to play that video back to the camera to gain access. Also, deepfakes exist. These concerns must be addressed before this module of web 4 reaches mass adoption.

The upside of biosecrets is they virtually cannot be lost, as the account should always be recoverable by the individual. In a web 4 ecosystem, where time tokens are distributed daily and often spent daily, a hack would be much less catastrophic. The attacker will be able to access the user's balance, but not alter the past transactions, nor continue to collect the future deposits, because the real user will (in theory) quickly recover the account and change the biometric secret generation means so that the hacker's biofake is no longer working. In a system where a user must remember the particular expression of their biokey, there is a greater chance that the user will forget, but a smaller chance of a successful fake.

3

Information Entropy

Web 3 focuses on storing information forever in a provable way. Web 4 introduces a counter-model which may be optionally adopted by any time-token-based system. In this model, who did what becomes harder and harder to know the more time that passes.

This idea hinges upon incremental time units, the number of which is used to decide how difficult information about a particular account or contract is to access. This can be implemented by increasing the difficulty required to verify a transaction chain, or economically by increasing the fees associated with accessing or interacting with old smart contracts.

With information entropy, it is difficult, but not impossible, to piece together a story about an individual user by knowing they are responsible for a set of transactions over time. The further back in time a transaction is, the harder it is to link it to another transaction with any certainty. This difficulty may be overcame with resources or tokens required to execute a smart contract.

An extension of this idea is to require more and more time tokens be accumulated by an account to interact with a smart contract. For example, you could require an account needs to receive 1 event participation token to interact with an event modification contract, then increase this requirement as more events take place, which would be represented by referencing passing time units in a smart contract.

Other examples can make it more expensive to change a record from the past, make it more expensive to join a group, change probabilities an action causes another action, or even limit any past state's effect on the future of a blockchain.

Information Entropy and Biosecrets

Information fidelity requirements can also be degraded over time. For example, when generating a user's biokey, it can be assumed that the more time that passes, the more the biometrics of the individual will change.

Degradation of Biokeys

Biokeys are generated from a range of biometric values. This range of values can be expanded over time based on specific, well researched paths. The effect is, instead of having one hashed biokey for eternity, the generation process will create a set of biokeys from an increasingly wide range of data. This concept may be needed to keep people in control of their accounts as they age. There is considerable work to be done to develop this concept, as each data type has its own considerations and complications.

In this case, as time goes on, someone attempting to prove their individuality would have to spend a lot more effort to run the algorithms against their collected biodata, and the data precision needed to match the person's identity is actually lower. This is an example of increasing information entropy lowering information fidelity. This is possible because of the granularity of the matrix used to generate a biokey. You can compute the millions of possible hashes related to these quantized pieces of data, and expand the acceptable range over time.

Proceed with Caution

While the inclusion of this concept into web 4 may seem unnecessary at the moment, it is another guarantee of the privacy that is needed for many social applications. Philosophically, degradation of information also fits in with the general web 4 desire to reflect systems in nature.

Before moving on, I do wish to stress the modularity of web 4, and that this (perhaps the most radical idea presented) is not going to fit into every web 4 system, nor should it. This idea will find its usefulness when it is time, and should NOT be adopted without clear reasoning.

4

GeoSocial Systems: Geotribes + Geodomains

Collaborative geosocial systems are always happening everywhere humans live. Currently, we are collectively deciding what direction we should be moving as a society, from representative governments, to social media. However, human growth in the past few centuries has been focused on technological improvements rather than social improvements. [3] To harness the power of the information age for the collaboration of humans, web 4 should be used to enhance, introduce, and replace current structures that organize our societies.

Web 4 proposes that geosocial systems based in time token are the most apt to create and improve existing social layers.

What is a GeoSocial System?

A geosocial system is something that affects people (social) at a given bounded area (geo). We will introduce a model to create a bounded geosocial system on blockchain.

Concepts

1. Geodomain: A bounded area that may contain or be contained by other geodomains and may have an associated group of people (geotribe).

2. Geotribe: The group of people associated with a geodomain that are participants in a web 4 system.

Geodomains are akin to a level of organization like city or state, with a finite set of smaller areas making up the larger area, with the smallest area being a community of humans with shared desires (such as how to live), and the largest area being Earth. Geodomains could be overlapping, or the geographic aspect can be replaced by a spatial or ideological relationship, like metaverse land or fans of sports teams. We will continue to focus on a geospatial aspect in relation to Earth geopolitics.

Geodomain Levels

Across the globe, one geopolitical (geodomain) pattern seems to emerge, though names vary. Communities are within Cities, are within Counties, are within States, are within Nations, are within the World.

1. Community
2. Cities (aka Towns, Commonwealths, etc.)
3. Counties (aka Divisions, etc)
4. States (aka Districts, Provinces)
5. Nations (aka Countries, States, Republics, etc)
6. Global

Using this existing geopolitical stratification is recommended for those wishing to build a web 4 system because it makes varying global systems easily storable in a one relational database model, smart contract, or similar data structure, and is understood by local people, governments, etc. Any other system is possible if one is willing to create it.

Once we have our geodomains, we must define what makes a geotribe.

Geotribal Bonds

Traditionally, it's a presence within a certain area, such as a place of residence or business, that is of importance for things like taxes, voting, and citizenship. This is no longer a necessity, as there are other metrics to measure an association with a region, including amount of time spent there (provable with checkins via a phone GPS) or voluntary declaration (proofless).

It is important for every system that each individual declare only one geodomain/geotribe so that their "vote" isn't counted twice, or half (if divided). Checking in once in a while within the region using GPS is an easy way to show association with a geodomain.

When using stratified geodomains, such as geopolitically-based ones, Geodomains are layered, with each level adding definition by refining larger Geodomain layers into smaller parts.

If a geopolitically-based geodomain system allows geotribe members to declare their own associated location without proof, the member is incentivized to be honest, as they will receive the most benefit from having their opinion heard where it matters to them.

All "non-proof" systems should place restrictions on switching voluntarily-given geodomain association too often (such as once per 6 months) to prevent influencing foreign affairs.

High-Fidelity Democracy

By offering time tokens to the individual that correspond to each stratum we can create high-fidelity democratic systems that better represent each and every person's desires. We can know exactly what the people want, with no guesswork and 0 middlemen, in a very short period of time.

For example, a person may be given 12 time tokens per month at each stratum to vote on the initiatives that they would like to see passed. They may vote all 12 tokens for an initiative they are most passionate about, or 1 token to 12 different initiatives (or 2 to 6 initiatives, etc). By collecting and counting these tokens, the governing body can know exactly what their constituents want, without the direct need to elect a representative who only estimates these desires.

The democratic system described in this paper does not solve all problems, as there are still issues of voter informedness, unseen actors, and more, but it is a skeleton to build a collaborative social system that are an improvement to the representative governments which were once as revolutionary as these ideas are.

The Road to Web 4 Reality

Phase One

Implementing time tokens

Time Tokens are implemented on any and all blockchains where developers see the value. These developers provide open-source instructions and tools to helps other developers incorporate time tokens into their applications. Services develop to allow any dapp to integrate a provider's time tokens.

Provable individuality for Time Token issuance is up to each application and blockchain, and these application can choose to ignore this requirement, risking their systems' integrity. Federated (Facetec) and decentralized (Civic) options may be used, and so can social verification (BrightID), as well as simpler development libraries for common web development frameworks like Vue, Angular and React.

Information entropy and geosocial systems are starting to be theorized, but not showing up.

Phase 1 Action Points:

• Time Token ERC proposal on Ethereum + EVM (and similar for other blockchains like EOSIO)
• Developers exploring use cases for Time Tokens

Phase Two

dApps and discovering issues

Applications using Time Tokens are widespread, and issues in implementations are becoming known and solved. Developers who open time token faucets are seeing their token be used in third-party apps in ways they didn't foresee.

Provable identity issues are becoming apparent, as certain applications with lax rules are being manipulated, showing the need for true provable identity. The best solutions are becoming known alongside the problems.

Information entropy principles are starting to be implemented, when required.

Geosocial systems are starting to be built, but not used for "real applications" like running a government because of lack of true provable individuality, and social inertia.

Phase 2 Action Points:

• Proposing the best uses for geosocial systems using time tokens
• Incorporating different provable identity methods
• Developers implementing Time Token in unexpected ways

Phase Three

Implementing Provable Identity

Provable Identity is now possible as suggested in this manifesto through the maturity of the biometric secrets. Standards are being created openly, or, it is decided that the way presented here is not needed as a better way is found. Or, biokeys are completely abandoned as a form of social verification is found that can replace it.

Geosocial systems are being used to run and govern communities which are not dependent on traditional representative government. Existing municipalities are adopting time tokens to get a better read on what legislation the people want.

Organizations of all sizes are using time tokens to shift power to employees.

Phase 3 Action Points:

• Picking proof of individuality solutions that satisfy all requirements
• Possibly abandoning biometric system presented here
• Communities running on web 4
• Governments benefiting from web 4
• Organizations using web 4

Phase Four

Geosocial systems

Information entropy is added to the systems where it can be of use. For example, this could make a person's (anonymous) voting record less knowable over time by increasing the amount of CPU time needed to associate one vote with another.

Geosocial systems are being used as a replacement for representative government where it is the will of the people. Voter informedness is measured and known, as are the exact desires of the people. This creates collaboration and a renewed faith in democracy, and a feeling of belongingness and appreciation for each individual.

Phase 4 Action Points:

• Building and operating geosocial systems for the benefit of society and any collaborating group
• Exploring use cases and integrating information entropy where appropriate

Author notes

Change Without Conflict

No one can stop us from building collaborative systems with web 4 and even self-governing. We don't need to "tear down the system" or separate from society to do so. Web 4 can exist fully embedded in the geopolitical systems around us, while implementing and improving the four concepts, the underpinnings of biomimetic democracy.

If and when the "old system" meets its demise, as all things do, we can transition rapidly to a web 4 system like Effective Collective or any other, as this solution will already be in place.

Why use the term "Web 4"

It is my belief that each version of the web must 1) be built on top of the previous version, 2) be fundamentally different than the previous version by introducing new technology, and 3) have meaningful impact on society.

This proposal for the next iteration of the web is an effort to both expand and shift the path of information science in a direction where the meaningful impact of society involves: 1) empowerment of each individual, which serve as the basis for collective (social), economic, and novel applications; 2) provable identity verification while maintaining complete separation from any federated system, including government, with the side-benefit of lifelong recoverability of biokeys with biosecrets; and 3) resonance with our contained and containing systems, like our human organs and the Solar system, which provide us with life and free energy daily, akin to free time tokens.

While an argument could easily be made that DeFi is Web 4, or another emerging tech, like "layer 2" blockchains (rollups) are web 4, both of these are not new. DeFi mimics and improves the systems of the past. Rollups are merely making web 3 more efficient.

It is my hope and desire that the information presented here will be expanded on and implemented by many developers and systems in the coming years, not for the benefit of the few, but for the empowerment of each individual and the harmony of the human collective, and every layer of Gaia.

Notes + References

[1] - Solutions like Civic and Facetec have proved to be effective in verifying individuality. KYC services rely on government-issued identification, physical signature, and minimal, often human-checked bioverification. Until the technology is developed for a biometric system resembling the ideas here, these options (as well as social verification) are viable, though not fully embodying the idea of web 4.

[2] - Hao, K. & O'Neill P. (2020, August 06). The hack that could make face recognition think someone else is you. Originally Published at https://www.technologyreview.com/2020/08/05/1006008/ai-face-recognition-hack-misidentifies-person/

[3] - Nishimura H., Kanoshima E., Kono K. (2019) Advancement in Science and Technology and Human Societies. In: Abe S., Ozawa M., Kawata Y. (eds) Science of Societal Safety. Trust (Interdisciplinary Perspectives), vol 2. Springer, Singapore. https://doi.org/10.1007/978-981-13-2775-9_2 (Specifically section 2.1.3)
web link

[4] - Face.io Integration Guide - Web link

See Changelog + Latest Updates: Web4 paper on Github

Appendices

Appendix A: Time Token Implementation

Here's a sample function to convert from timestamp to a time unit. Time-based systems don't always need a token linking the account owner, and you can compute from native time types.

// --- Returns the current Time Unit --- \\
function getTu() { // Returns the current Time Unit
  // 1561139700 is the first Time Unit
  let nowts = new Date().getTime(); 
  let tu_ = Math.floor((Math.floor(nowts/1000) - 1561139700) / 300);  // Divide by the length of a Time Unit in seconds
  return tu_;
}//END getTu()

Here's an example of a smart contract structure implementing the time token concept on EOSIO blockchain technology to make a democratic music map. The missing functionality in this example is the distribution of Time Token, handled in another contract.

In this contract, the tokens used to do the voting are Time Tokens for the dapp cXc.world. The contract listens for transfers of this time token to the contract, and assigns an equal amount of weight to each vote in logup(). To view the full contract an actions, review the open-source contract on Github and to understand what the concepts are, view the explainer document.

#include "eosio/eosio.hpp"
#include

using namespace std;
using namespace eosio;
using std::string;

class [[eosio::contract]] ups : public contract {

using contract::contract;
public:

#include "songs.hpp"

struct song {
string title;
vector links;
vector geoloc;
uint8_t genre;
uint8_t mood;
uint8_t format;
string atomictempid;
};

uint32_t timeunit;

std::string AUTH_ACCOUNTS[6] = { "authorized", "accounts" };

enum up_type {
SOL = 1,
BLUX = 2,
BIG = 3,
BIGSOL = 4 // -- This allows one call to send both Sol and Big Ups, greedy for all 64 Ups to make one Big Up (Won't work otherwise)
};

private:

TABLE upslog {
uint upid;

uint32_t songid;
uint32_t totalsolups;
uint32_t totalbluups;
uint32_t totalbigups;
uint32_t tuid;

  uint64_t primary_key() const { return upid; }
  uint64_t by_songid() const { return (uint64_t) songid; }
  uint64_t by_solups() const { return (uint64_t) totalsolups; }
  uint64_t by_bluups() const { return (uint64_t) totalbluups; }
  uint64_t by_bigups() const { return (uint64_t) totalbigups; }
  uint64_t by_tuid() const { return (uint64_t) tuid; }
};

using upslog_table = multi_index<name("upslog"), upslog,
  eosio::indexed_by<"bysongid"_n, eosio::const_mem_fun<upslog, uint64_t, &upslog::by_songid>>,
  eosio::indexed_by<"bysolups"_n, eosio::const_mem_fun<upslog, uint64_t, &upslog::by_solups>>,
  eosio::indexed_by<"bybluups"_n, eosio::const_mem_fun<upslog, uint64_t, &upslog::by_bluups>>,
  eosio::indexed_by<"bybigups"_n, eosio::const_mem_fun<upslog, uint64_t, &upslog::by_bigups>>,
  eosio::indexed_by<"bytuid"_n, eosio::const_mem_fun<upslog, uint64_t, &upslog::by_tuid>>
>;

TABLE totals {
  uint32_t songid;
  uint32_t totalsolups; 
  uint32_t totalbluups;
  uint32_t totalbigups;
  uint32_t updated;

  uint64_t primary_key() const { return songid; }
};

using totals_table = multi_index<name("totals"), totals>;

TABLE songs { //CHECK need to store the type of account here?
  uint32_t songid;
  name artistacc;
  uint8_t artisttype;
  song song;

  uint64_t primary_key() const { return (uint64_t) songid; }

};

using songs_table = multi_index<name("songs"), songs>;

// --- Activity stats for Listeners (For future awards) --- \\
TABLE listeners {
  name upsender;
  uint32_t firstup;
  uint32_t lastup;
  uint32_t totalsolups;
  uint32_t totalbluups;
  uint32_t totalbigups;

  uint64_t primary_key() const { return upsender.value; }
};

  using listeners_table = multi_index<name("listeners"), listeners>;

// --- Store record of who to pay --- \\ 
// CHECK (in .cpp) that we are paying both the upsender + upcatcher
TABLE ious {
  uint64_t iouid;
  name upsender;
  name upcatcher;
  uint8_t artisttype;
  uint32_t upscount; // Should be either BIGSOL or sol up or both
  uint8_t upstype;
  uint32_t initiated;
  uint32_t updated; 

  uint64_t primary_key() const { return iouid; }
  uint64_t by_upcatcher() const { return upcatcher.value; }
  uint64_t by_artisttype() const { return (uint64_t) artisttype; }
  uint64_t by_upscount() const { return (uint64_t) upscount; }
  uint64_t by_initiated() const { return (uint64_t) initiated; }
  uint64_t by_updated() const { return (uint64_t) updated; }
};

using ious_table = multi_index<name("ious"), ious,
  eosio::indexed_by<"byupcatcher"_n, eosio::const_mem_fun<ious, uint64_t, &ious::by_upcatcher>>,
  eosio::indexed_by<"byartisttype"_n, eosio::const_mem_fun<ious, uint64_t, &ious::by_artisttype>>,
  eosio::indexed_by<"byupscount"_n, eosio::const_mem_fun<ious, uint64_t, &ious::by_upscount>>,
  eosio::indexed_by<"byinitiated"_n, eosio::const_mem_fun<ious, uint64_t, &ious::by_initiated>>
>;

// --- Keep record of Artists (recipient in _songs) to pay --- \\
TABLE artists {
  name artistacc;
  string artistalias;
  vector<string> artistinfo;

  uint64_t primary_key() const { return artistacc.value; }
};
using artists_table = multi_index<name("artists"), artists>;

TABLE artistgroups {
  string groupname;
  name intgroupname; // abcdef.cxc // CHECK is there benefit to a name (uint64_t) vs a simple uint32_t? 
  vector<name> artists;
  vector<int8_t> weights;
  vector<string> groupinfo; // CHECK this will work, can pass empty strings, or is there an <auto> type, key value pairs
  uint8_t payposition;  

  uint64_t primary_key() const { return intgroupname.value; }
};

  using groups_table = multi_index<name("artistgroups"), artistgroups>;



TABLE internallog {
  uint32_t lastpay;
  uint32_t lastfullpay; 
  bool remaining; // Did we reach the end of who is owed to pay? 

  uint64_t primary_key() const { return (uint64_t) lastpay; } 
};

using cxclog_table = multi_index<name("artistgroups"), artistgroups>;


void updateup(uint32_t upscount, uint8_t upstype, name upsender, uint32_t songid); 
void logup(uint32_t upscount, uint8_t upstype, name upsender, uint32_t songid); 
void removeups(name user); 
void updateiou(uint32_t upscount, uint8_t upstype, name upsender, uint32_t songid, bool subtract); 
void removeiou(name sender, name receiver); 
void updatelisten(uint32_t upscount, uint8_t upstype, name upsender);
void removelisten(name upsender);
void removesong(uint32_t songid); 
void deepremvsong(uint32_t songid); 


void updateartist(name artist_wax, vector<string> artistinfo, string artistalias); 
void updateartistgroup(name intgroupname,  vector<string> groupinfo, string group_alias, vector<string> artists, vector<int8_t> weights);


// --- Declare the _tables for later use --- \\ 
ious_table _ious;
upslog_table _upslog;
songs_table _songs;
listeners_table _listeners;
artists_table _artists;
groups_table _groups;
totals_table _totals;

public:

[[eosio::on_notify("sol.cxc::transfer")]] 
void sol_catch( const name from, const name to, const asset quantity, const std::string memo );

ACTION payup(void); // Default call

ACTION payup(name upsender); // User's call to pay themselves

ACTION updateartist(name upsender, vector<string> artistinfo, string artistalias);

ACTION updategroup(name intgroupname, string group_alias, vector<string> artists, vector<int8_t> weights, vector<string> groupinfo);

ACTION updatesong(uint32_t songid, song dasong); 

};

Appendix B: Pseudocode Example of Biometric Function

function bioKeyGenerator(bioData){

    // Function takes data in the form of user input into their browser or smartphone.

    let recievedData = bioData;

// With data, quantifyable points are taken algorithmically
let processedBioData = {
    point1:recievedData.point1,
    point2:recievedData.point2,
    point3:recievedData.point3
    ...
}



    

    




// These points expanded to a pre-defined margin of error geometrically for each input type

const expander = 20; // Set amount to expand dataset based on data type

let rangedBioData = {

    point1: {

        upperRight: {

            x : processedBioData.point1.x + expander,

            y : processedBioData.point1.y + expander

        },

        lowerLeft: {

            x : processedBioData.point1.x - expander,

            y : processedBioData.point1.y - expander

    },

    point2: {

    ...

    },

    ...

}

let snappedBioData = snapBioDataToGranularPath(rangedBioData);

// For this to work, a matrix-like object containing every single possible hashed value for every point of data

// ..must be stored on an authentication server for each data input.

// Data must also exhibit granularity (snap to an integer path).

// Without granularity, the hashes will never match a new input's hash.

// This matrix of values is used to compare the biokey with in the future

// This must be made more efficient to use with today's computers

let x;

let y;

let bioMatrix = {};

for (x = snappedBioData.point1.lowerLeft.x; x <= (expander*2) ; x++) {

    let curXRow = "x"+x;

    let bioMatrix[curXRow] = [];

    for (y = snappedBioData.point1.lowerLeft.y; y < (expander*2) ; y++) {

        curYRow = "y"+y;

        bioMatrix[curYRow].push(sha256(y));

    }

}

// Finally, the real biokey is returned as an object of hashed biometric data, 

// which will be checked by comparing each granular piece of data's hash to the incoming granular hashes

return bioMatrix; // Biokey

}

function snapBioDataToGranularPath(rangedBioDataParam){

    //returns data snapped to grid (recursively scans object passed)

}

Pretty Photos of the Code

Image Credits

Paper by Douglas James Butner
douglas@cxc.world

👉 Passionate about these ideas? Support us on Gitcoin ☕️