In the absence of trust . . . opportunities for mutually beneficial cooperation would have to be foregone . . . norms of social behavior, including ethical and moral codes [may be] . . . reactions of society to compensate for market failures. (Kenneth Arrow wrote in 1971 p. 22) Thus, social preferences such as a concern for the well-being of others and for fair procedures remain essential to sustaining society and enhancing the quality of life. In a world increasingly connected not just by trade in goods but also by the exchange of violence, information, viruses, and emissions, the importance of social preferences in underwriting human cooperation, even survival, may now be greater even than it was among that small group of foragers that began the exodus from Africa 55,000 years ago to spread this particular cooperative species to the far corners of the world. Bowles, Samuel; Gintis, Herbert. A Cooperative Species (p. 200). Princeton University Press. Kindle Edition.
Human beings have become more conscious of a growing interdependence between all parts of the world with the growth of a world economy which followed the Great Transformation, the Services Transformation, the ICT revolution, the adoption of free trade policies, named as the New Globalization by most of the countries of the world.
A beginning to understand, though dimly, that no country is an island unto itself, but as Bahá’u’lláh said: “The earth is but one country, and mankind its citizens.”
Without a strong guiding moral philosophy men struggled on as best they could to respond to the new needs of the world. It is accepted that the times called for a more just dignified station for a much wider spectrum of the society.
The world is nowadays dominated by a growing divide, a term that reflects the availability or unavailability of Information Technology and Communications (ICT) resources, analysed in terms of its economic accessibility. This is called the digital divide.
Questions arise how human beings can address this look for trust, worldwide, increasing the digital inclusion.
The world - is still- dominated by two extreme visions: one that denies the radical changes in patterns of communication that the ICT revolution entails and the other that denies the persistence of an economy based on the physical constraints imposed by location and the material nature of most goods and products.
The problems and opportunities detected are the advent and use of ICT to transform patterns of communications and that businesses are not fully aware on how these technologies should be used to create appropriate communication in order to be more productive. Communication that is acceptable for people both being a customer and a human being.
Victor Frankl, facing the purpose of life, is best cured by going outside, extending the self rather than contracting it, in service to others, in upholding a value, in embracing suffering positively rather than negatively.
Such service can be made more effective the more skills a person has.
Knowledge is as wings to man’s life, and a ladder for his ascent. Its acquisition is incumbent upon everyone. To encourage education as much as possible in sciences which will increase the capacity for service, as well as the moral teachings.
ICT when used properly, it can increase productivity, reduce risk, and increase accessibility, specially when people are faced with distance.
An electronic payment system based on cryptographic proof instead of trust could help when there is distance, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.
Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust-based model. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.
Cryptographic proof. Here is the mathematical “magic” of Bitcoin: the ability to assess the integrity of records and verify new data, instead of relying on the bank, the state, the law or the authority of any other institution.
How? Cryptographic hashing is a mathematical phenomenon whereby some data is run through a hashing algorithm, which will then output a string of characters. Only this particular data run through this particular hashing algorithm will produce that specific string of characters. What this means is that if the data is tampered with in any way, this can be proven by running it through the hashing algorithm again and checking if the output is the same. Here is a cryptographic proof.
Replacing “trust” with cryptographic proof promised to replace the uncertainty of humans and institutions with the certainty of mathematics, and yet cryptographic hashing is itself an area of human endeavour.
Hashing is a discovery of universal principle that all else can be anchored to; for others, it is an area of research and invention, but is also an area of creativity, knowledge sharing and collaboration amongst peers experimenting and working with the phenomena of this curious universe we live in.
The Double spending Problem. How does a decentralised network reach consensus on which transactions are true? The solution to the double spending problem using peer-to-peer distributed time stamp server to generate computational proof of the chronological order of transactions.
The blockchain and the internet could be applied to different needs of human beings. The first need is for the individual, then agreement between peers.
Your Digital ID or the Digital ID of your organization must be irreplaceable. We must assure a secure world, peaceful, and without setbacks produced by hackers or identity theft.
DNS and social media are based on the Internet domain name system, names are globally unique and human-readable, but not strongly owned. The system operator has the final say as to what each name resolves to. This requires that client must trust the system, and trust that the administrators are the only ones that can make these changes.
Several attempts to use cryptographic names have been tested, from the keys they reference. But these names are difficult for most users to remember since they do not carry semantic information relating to their use in the system.
Bitcoin Name Service BNS have all these properties, and none of these problems. This makes it a powerful tool for building all kinds of network applications. Using the BNS, the following can be achieved and more:
• Build domain name services where hostnames cannot be hijacked.
• Build social media platforms where user names cannot be stolen by phishers.
• Build version control systems where repository branches do not conflict.
• Build public-key infrastructure where it is easy for users to discover and remember each other's keys.
Software applications built with the Stacks blockchain integrated, give users control over their digital identities, assets, and data. Unlike most cloud-based apps, they are "decentralized" since they do not depend on any centralized platform, server, or database to function. Rather, they use the Stacks blockchain to authenticate users and facilitate read and write requests for them without any single point of failure or trust.
This kind of ID is called Decentralized ID. It uses cryptography, digital wallets and related technologies to enable multiple entities to contribute credentials and empower individuals to manage their data. Decentralized ID systems create a trust triangle that links issuers, holders and verifiers: issuers are entities that digitally sign attestations and provide them to holders; holders, such as individuals, manage their credentials and use them to prove claims about their data; and verifiers assess these attestations to determine whether they satisfy requirements. This process, which can be facilitated by a verifiable data registry.
The Stacks blockchain addresses performance problems using a layered approach. The base layer consists of the Stacks blockchain, and the Blockchain Naming System (BNS). The blockchain governs ownership of identities in the Stacks network. Identities can be names such as domain or subdomain names, or application names.
Decentralized Applications (Dapp’s) is the New App that integrates these main functions, authentication, transaction signing, and data storage. All users can run their applications under their own private decentralized space. Each user has access to and/or shares with other users its own private data through the decentralized application. These domain or subdomain names are called decentralized names or decentralized IDs, and they are registered to the public key associated to its private key or address, through a name registry implemented in a smart contract on Stacks, secured by Bitcoin. The provable smart contract is written in Clarity, a safe, decidable language. The contract links the STX address and the username according to the rules about fees and expiry.
Names in BNS have four properties: • Names are globally unique. The protocol does not allow name collisions, and all well-behaved nodes resolve a given name to the same state. • Names are human-meaningful. Each name is chosen by its creator. • Names are strongly owned. Only the name's owner can change the state it resolves to. A name is owned because the owner of its private key can generate valid transactions that update its zone file hash and ownership. The name zone file can only have a valid verification using the owner’s private key. • Names using its associated public and private key can sign transactions. Only the owner of the name and the associated keys can sign in a verifiable way transactions, and the execution of the smart contracts in a decentralized way. This action represents the unique action of a user, that has access to those keys.
A user private and public keys are based from the mathematical, and cryptographical algorithm, and they are to base to use it in the Stacks or Bitcoin blockchain.
From a private key the user can derive a decidable public key in a Stacks address format, and in several Bitcoin addresses format. Actual Stacks 2.1 have methods accepting more BTC address formats (P2PKH, P2SH, P2WPKH, P2WSH, P2TR). A Stacks address starts with a “SP”.
Initially, the Bitcoin address was based on the legacy address P2PKH starting with a “1”, the actual ones are based on SegWit address P2WPKH starting with a “bc1”, and Taproot address when massively available starting with a “bc1p”.
These addresses are mathematically or cryptographically linked together as one or the same, but they are used in the Stacks or Bitcoin blockchain ecosystem respectively.
The Stacks blockchain ensures that each node's BNS view is synchronized to all the other nodes in the world, so queries on one node will be the same on other nodes. Stacks blockchain nodes allow a name's owner to bind up to 40Kb of off-chain state to their name, which will be replicated to all other Stacks blockchain nodes via a P2P network.
The biggest consequence for developers is that in BNS, reading name state is fast and cheap but writing name state is slow and expensive. This is because registering and modifying names requires one or more transactions to be sent to the underlying blockchain, and BNS nodes will not process them until they are sufficiently confirmed. Users and developers need to acquire and spend the requisite cryptocurrency (STX) to send BNS transactions. At another level, the different applications could interact among them exchanging information. In order to use these capabilities, a set of standard verifiable digital identities should be used integrated into the web to have a secure and private interaction.
A request for a transaction or change of state of the Blockchain requires the use of the private key to sign, and funds as gas to materialize the order. To improve security, and reduce the risk of losing control of the private key of an account, different methods have been developed, trying to avoid entering it directly to the application.
For the use of web applications, it requires the use of a browser wallet software plugin, that has access to the private key directly or using a hardware device.
At present in the Stacks ecosystem, there are two browser wallet software available. One is the Hiro Wallet (https://wallet.hiro.so/) for desktop PC’s, and Xverse Wallet (https://www.xverse.app/) for mobile devices.
The Stacks zone files have the capabilities, and the tools to define the profiles for the application itself, and each of its users, depending on the application to identify its subjects, in a decentralized way using the Internet.
The W3C (https://www.w3.org) recommends Decentralized identifiers (DIDs), as a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides to identify. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID.
The DIDs for a person for example, are expressed through a name and an image, sometimes a description, background image, url, email, password signature, etc. The visual and textual representation of an account, helps users to better recognize their own accounts, from the accounts of other users. Stacks has a long history of Decentralized Identifiers (DIDs) as they introduced human readable names for bitcoin addresses when the project started as “One Name” back in 2014.
The Stacks public DIDs is a profile that is registered with a username on-chain using the BNS (Blockchain Naming System) smart contract. These profiles are defined using the JSON web token, and its contents using the appropriate objects of the Schema standard (https://schema.org), like the person object (https://schema.org/Person).
BNS names can be compliant with the emerging Decentralized Identity Foundation (identity.foundation) protocol specification for decentralized identifiers (DIDs), and the W3C foundation. These initiatives define mechanisms by which an End-User can leverage an open provider to release identity information (such as authentication and claims) to a Relying Party which can act on that information.
Each name in BNS has an associated DID. The DID format for BNS is: • did:stack:v2:{address}-{index} • did:btc-addr:{address}-{index}
Where: • {address} is an on-chain public key hash (for example a Stacks or Bitcoin address). • {index} refers to the nth name this address created.
To incentivize mass adoption of DIDs, one initial strategy is to link both Internet Domain Names to DIDs, both referring to each other, in the BNS zone file a reference to a web server, and in the Internet domain server referring to the respective DID. Mixing a centralized domain names with the decentralized domain names. For example, the Internet domain name XCK.app refers to the Stacks DID XCK.app, and both are owned by the same controller. In this case, the controller should be the dapp.
This strategy is ratified by a recent proposal in using a new DID method in conjunction with blockchain-based DIDs that allows them to bootstrap trust using a web domain's existing reputation (https://w3c-ccg.github.io/did-method-web).
Typically, the domain and subdomain names have commonly used Latin characters in ascii format. Due to the convergence of the use of different languages, and character systems, the popularity in social apps, people have started to think about using emoji as names for their domains or subdomains.
The compatibility of the dapps with Punycode could be a facilitator of mass user adoption. For example: 🧑💼 .xck.app is represented as xn-- -zc3sr5i.xck.app
In order to have higher level of adoption, increases the desire to have communications, and interoperability between users cross blockchains ecosystems like Stacks, and Bitcoin. One example, is Nostr, that uses the public key as unique identifier, that is linked to the DNS.
Each App (web application) should have a verified identity in order to safely reference it and be trustworthy of interaction between other applications. An app can be identified both by the Internet domain (DNS) for example 'XCK.app' and the Stacks DID 'XCK.app' In case, it is a web application, it could be accessed as https://xck.app having both definitions. In this case, we using the trust of the Internet domains to match the Decentralized Domains (DID).
The description for an App Profile document should be done using a JSON web token based on the WebApplication Schema object (https://schema.org/WebApplication). Additionally, this App Profile document must include the did-method-web. The example is represented as 'did:web:xck.app'. The target system of the Web DID method is the web host that the domain name described by the DID resolves to when queried through the Domain Name System (DNS). This did-method-web must be included in this app profile.
It could be useful to have a way to retrieve a verifiable DID profile for the App as recommended by the W3C using an URI. For example, a web URI https://xck.app?.well-know/profile In this case, the application should also return a JSON web token using the protocol previously mentioned.
Creating a DID is done by: applying at a domain name registrar for use of a domain name and storing the location of a hosting service, the IP address at a DNS lookup service creating the DID document JSON-LD file including a suitable keypair, e.g., using the Koblitz Curve, and storing the did.json file under the well-known URL to represent the entire domain.
For example, for the domain name 'xck.app', the 'did.json' should be available under the following URL: 'did:web:xck.app' -> https://xck.app/.well-known/did.json
Example of the 'did.json' file for 'XCK.app'
{
"@context": "https://www.w3.org/ns/did/v1",
"did:web": "xck.app",
"verificationMethod": [
{
"id": "did:web:xck.app#OAuth",
"type": "Secp256k1",
"controller": "did:web:xck.app:oauth",
"stacksAddress": "SP3YK7KWMYRCDMV5M4792T0T7DERQXHJJGGEPV1N8"
}
],
"authentication": [
"did:web:support.xck.app#OpenID",
"type": "Secp256k1",
"controller": "did:web:xck.app:oid",
"stacksAddress": "SP3YK7KWMYRCDMV5M4792T0T7DERQXHJJGGEPV1N8"
]
}
Expanding the Internet Domain Names to the users of Decentralized Identifiers (DID) For the users of each App (web application), the App could provide a verified user identity in order to safely reference across other applications. In this context, the DIDs are URIs that associate a DID subject as a user of the application with a DID document allowing trustable interactions associated with that subject.
The BNS Bitcoin Name System has the possibility to create subdomain names under a defined decentralized domain name. A user can inscribe a subdomain name, having the attribute of a DID. For example, the user 'support', using the domain name ‘xck.app’ is 'support.xck.app' In the example used here, the user is identified by this subdomain name, and it could be useful to retrieve a verifiable DID profile for the App User as recommended by the W3C using an URI. For example, a web URI https://support.xck.app/.well-known/profile
The BNS implement a way to store the description for a User Profile document using the Person Schema object (https://schema.org/Person). The BNS has the possibility to associate a zone file to each Stacks address. In the zone file there is a reference to the location of a profile.json file, where the user profile is saved, with a hash in a JSON web token format. The web token assures that only the user can sign the profile in the blockchain. If the profile is altered by somebody else of the owner, the profile file would not match the JSON web token.
Also, this document must include the did-method-web for the app user. For the user support.xck.app as an example, it is represented as 'did:web:support.xck.app'. The target system of the Web DID method is the described web host resolved by the Domain Name System (DNS) when queried. This did-method-web is included in this app user profile.
In this case, the application should also return a JSON web token using the Person Schema object.
Example of the Person JSON web token included in the profile for support.XCK.app
{
"header": {
"typ": "JWT",
"alg": "ES256K"
},
"payload": {
"jti": "a7ad5f4f-0f6b-4674-903c-e0c9acd542af",
"iat": "2023-06-16T22:59:11.416Z",
"exp": "2024-06-16T22:59:11.416Z",
"subject": {
"publicKey": "031f6416b88fc084c12edc8aa052d9408513793a832a9546d768cb90ba6e6875d5"
},
"issuer": {
"publicKey": "031f6416b88fc084c12edc8aa052d9408513793a832a9546d768cb90ba6e6875d5"
},
"claim": {
"@type": "Person",
"@context": "https://schema.org",
"apps": {
"https://xck.app": "https://gaia.blockstack.org/hub/1EqMMnscqw4BExURkxjamnyW47aqQSKmwV/",
"https://explorer.stacks.co": "https://gaia.blockstack.org/hub/13gRiYdPQnDyhSjmuAoKpsYHRCxapP5opi/",
….
},
"appsMeta": {
"https://xck.app": {
"storage": "https://gaia.blockstack.org/hub/1EqMMnscqw4BExURkxjamnyW47aqQSKmwV/",
"publicKey": "0250eff373ca36b72aa4fdb6a7fc201829b2a7c5ccf7b7196e5b6b6b734facbe84"
},
"https://explorer.stacks.co": {
"storage": "https://gaia.blockstack.org/hub/13gRiYdPQnDyhSjmuAoKpsYHRCxapP5opi/",
"publicKey": "0269903a668f1a3fd3f17528b3fb70c75cff910bbe456f3811ade975dba473f71a"
},
…,
},
"name": "Support CrossCheck",
"description": "The CrossCheck(c) Dapp requires sometimes a support service. This account represents the support service that it is given to CrossCheck users.",
"sameAs": [
"https://www.facebook.com/checkParadigma",
"https://twitter.com/xck_app",
"https://www.youtube.com/@crosscheckxck",
"",
"https://www.linkedin.com/company/52113400",
"",
"https://xck.app"
],
"email": "[email protected]",
"telephone": "",
"telephoneCountry": "",
"telephonePrefix": "",
"potentialAction": [
"Public",
"",
"Public",
"",
""
],
"contactPoint": [
"Active",
"false",
"true",
"true",
"true",
"true",
"true"
]
}
},
"signature": "kMzVsEoLOLn3HpsJu2vyY2SHQ_zTQj4-anUihtvDd1G2mkaWcS4Jee57r4M60CU1JA-51J14E7qGj7FwLESELw"
}
In case, the did:web does not match the domain name, it could be used with an alternative url. All Stacks decentralized ID (did:web) have access to the did.json file.
Example: did:web:my.xck.app/paradigma.id --> https://my.xck.app/paradigma.id
Creating a DID is done by: applying at a domain name registrar for use of a domain name and storing the location of a hosting service, the IP address at a DNS lookup service creating the DID document JSON-LD file including a suitable keypair, e.g., using the Koblitz Curve, and storing the did.json file under the well-known URL to represent the entire domain.
For example, for the domain name 'support.xck.app', the DID document should be available under the following URL: 'did:web:support.xck.app' -> https://support.xck.app/.well-known/did.json
Example of the 'did.json' file for 'support.XCK.app'
{
"@context": "https://www.w3.org/ns/did/v1",
"did:web": "support.xck.app",
"verificationMethod": [
{
"id": "did:web:support.xck.app#OAuth",
"type": "Secp256k1",
"controller": "did:web:support.xck.app:oauth",
"stacksAddress": "SP3VBHA63ZTZFWTBJWHV775WR3PBZ64B26AYX2CF"
}
],
"authentication": [
"did:web:support.xck.app#OpenID",
"type": "Secp256k1",
"controller": "did:web:support.xck.app:oid",
"stacksAddress": "SP3VBHA63ZTZFWTBJWHV775WR3PBZ64B26AYX2CF"
]
}
This did.json references the blockchain account associated to the DID, and the method to be used to verify if a message hash has been signed by the user.
Also, did.json file specifies the method to be used for the authentication of the user into an application.
In case, the did:web does not match the domain name, it could be used with an alternative url. All Stacks decentralized ID (did:web) have access to the did.json file.
Example: https://my.xck.app/paradigma.id/.well-known/did.json
{
"@context": "https://www.w3.org/ns/did/v1",
"did:web": "my.xck.app:paradigma.id",
"verificationMethod": [
{
"id": "did:web:my.xck.app:paradigma.id#OAuth",
"type": "Secp256k1",
"controller": "did:web:my.xck.app:paradigma.id:oauth",
"stacksAddress": "SP1X4571GM6232GPQ7MW44HGTNX5TH3PKJQR6H7K8"
}
],
"authentication": [
"did:web:my.xck.app:paradigma.id#OpenID"
"type": "Secp256k1",
"controller": "did:web:my.xck.app:paradigma.id:oid",
"stacksAddress": "SP1X4571GM6232GPQ7MW44HGTNX5TH3PKJQR6H7K8"
]
}
SSO authentication is the process of logging in to a network once and then being able to access all the other systems within the same network using the same credentials. A user can log in once and have access to all the systems associated with their account. SSO authentication is used for cloud-based applications, web applications, and mobile apps and so on.
Many services are provided through web applications and the number of applications is increasing rapidly. The same sign on login information is also used by many of these users.
For example, a single-click login is available with OpenID-enabled services like Google, and Facebook. Also, custom Single Sign-On (SSO) provides additional security to protect identity and authentication.
However, centralized authentication has major security vulnerabilities with a single point of failure. Many developments have been made in recent years to address these weaknesses in authentication, and the answer is clear. Security risks can be mitigated by using blockchain-based SSO authentication, which is more secure, cost-efficient, and reliable
The BNS infrastructure, including the Profile, did:web specification could be used to develop a Application Single Sign On (SSO). The decentralized applications typically use the web Wallet for authentication. But probably, there could be an additional level of authentication compatible with the traditional SSO to access the decentralized applications, but when these applications require to sign, and send Blockchain transactions, the web Wallet are used for that purpose.
The described methods above in 4.3 for verification, and authentication, could serve as single sign on a platform based on the Stacks and Bitcoin blockchain to access any application any place in the world. The definition of this way of authentication is owned by the user, and enabled by cryptographic technology.
This Sign On infrastructure does not require to access directly the different blockchain ecosystems, it is through the user published methods. It is a initial step to massify the adoption of DID’s.
It will be important to define a standard protocol for each of the methods, the verification and authentication. Probably, the OpenID4VC (Open ID for Verifiable Credentials) standard could be used as a base. But the benefits of using an authentication based on Blockchain is much robust, secure, and private than the traditional methods of authentication.
Did:web users can register their ID in compatible applications, probably from different blockchain networks. These applications could retrieve directly the user’s validated profile data, avoiding the re-entry of information to the application. Having also the possibility the ownership of an identity using the verification and authentication methods.
A did:web could bring each individual, business or organization a verified identity web presence. Or, to share their contact details, kind a visiting card, but digital and verified.
The web presence inclusion option for every inhabitant of the world could be possible, using the did:web, and their owned SSO to any application. Tapscott, describes a higher level of digital capital when applications can integrate to each other.
In some specific use cases, probably, more in the formal space, some legal and business processes, its deliverables, and some cross border transfers, require that the participant users be identified by some valid legal national ID. DID profiles could be ideal to bound them a valid national identity document.
Using a blockchain technological solution to bound a user's national identity document, for example, a national passport or national ID card, permitting a DID to be used by the user. This is an authorizing and bound process to the DID, as a proof of identity. When users are interacting in a transfer or business agreement, this identity attribution could be shared between them. This utility of proof of identity could satisfy KYC (Know Your Customer) requirement of some country governments. In this case, regulation, executed in a decentralized way, controlled, and owned by each user.
The proof identity should be an inscription of a DID bound to a National ID document, maintaining privacy, and security. The user could share its proofs of identity with the corresponding peers, when necessary, with the correspondent National ID Inscription. This type of inscription could be considered as Soulbound tokens (SBTs), a proposal for enabling non-transferrable cryptoassets that represent commitments, credentials and affiliations.
Another complementary Proof of Identity solution could be done by the reference of other users, that they know a certain user. Kind of a reputation ranking, like for example (https://trajan.app). At a certain, point one or more of the sponsoring users must have a more solid proof of identity issued by a valid legal national ID. These referrals can also be indicated in the user profile.
Apps built with the Stacks blockchain can store off-chain data using a storage system called GAIA (by Stacks). GAIA is a unique approach to decentralized storage that focuses primarily on user-ownership of data, rather than immutable on-chain storage. In this case the emphasis is on the user control.
While on-chain storage solutions like IPFS and Arweave are designed for immutable, censorship-resistant permanent storage, they cannot be deemed as providing user control of the data since the user cannot modify or remove the data once it has been deployed.
GAIA solves a different problem of allowing users to be in control of where their data is stored while connecting the access of that data to their on-chain Stacks identity.
Whereas public transactional metadata is best stored on the Stacks blockchain, user application data can often be stored more efficiently and privately in Gaia storage.
Storing data off the blockchain ensures that Stacks applications can provide users with high performance and high availability for data reads and writes without introducing central trust parties.
When the user logs using its BNS name in to an application, the authentication process gives the application the URL of a Gaia hub, which performs writes on behalf of that user. The Gaia hub authenticates writes to a location by requiring a valid authentication token, generated by a private key authorized to write at that location.
Gaia's approach to decentralization focuses on user-control of data and storage. If a user can choose which Gaia hub and which backend provider to store data with, then that is all the decentralization required to enable user-controlled applications.
The Apps objectives could suggest to use alternative solution to store data associated to a BNS name. The option of using distributed file system like IPFS, or Arweave, or messaging services like Mastodon, or Matrix, among other type storage services, will be an area of intensive growth in the next years as the decentralization process turns mainstream.
c) Essentially, these technologies will try bring to market the capacities of the design of Distributed Databases.
A proposal of extending Stacks component was proposed by us in this study (https://github.com/paradigma-cl/stackscomponents).
Immutability is an attribute that Blockchain technology offers to world society. A transaction, and/or the execution of a smart contract that cannot be altered.
This attribute of immutability could be transformed in an inscription service applied to different purposes. The first example of this type of service is the BNS, and the second NFT inscriptions for art or music work. Other examples taken from XCK.app are the business Agreements Inscriptions, payments, and business Deliverables Inscriptions. Ordinal inscription is another emerging inscription type stored directly on the Bitcoin blockchain.
Some of these inscriptions could be considered also as Soulbound tokens (SBTs), enabling non-transferrable cryptoassets, specially for business Agreements, and business Deliverables.
The Stacks blockchain smart contracts can leverage the usability of the Bitcoin ecosystem, could help manage the inscription process of Ordinals that has started recently. An inscription is not sufficient as a solution of being the first doing it. It should have management rules, that users abide to, in order to have real meaning, and value. The BNS can be used to acquire, manage, and distribute ordinal inscription, as other type of inscription assets, both in the Stacks or Bitcoin ecosystems.
Inscriptions could be leverage with the use of did:web for the users, and apps. An app inscription or an inscription executed by a user could be accessed publicly by a web service using the did:web protocol. So ideally, Blockchain Inscriptions could be turned into a standard Stacks Improvement Proposals - SIP. This standard could boost usability among other applications that reference this blockchain inscriptions. TXT records could be used at the zone file to connect BNS domains with inscriptions at ordinals.
A market of exchange of DID domain name is already operating. Since the BNS lets any domain name owner to transfer its property to another user, there has been interest specially among early adopters to save some “key” names for future users, also as the STX exchange value is still low. There have been some proposals to change the behaviour of the BNS to facilitate storing list of domain names for future exchange. An example of an application that tries to help manage and saving different DID domain names is BNSx.
In the case of DID subdomain names is different, as the list maintained under its DID domain name in the zone file. Each DID subdomain name owns its own zone file specification, profile file, and its valid hash. The owner of the DID domain name is the only one that can update the list of subdomains under its domain name. For the exchange of subdomain name between one user to another, the domain name owner must provide a service to transfer its ownership, and executes in behalf of the owner.
Nowadays, the most common use for the blockchain, agreed by several country’s Central Banks, it is its capacity to make cross border assets transfer efficiently.
Lately, the exchange of pieces of digital art using non fungible tokens, and similarly Ordinals in the Bitcoin network, have attracted the attention generating high level of transaction traffic.
Nevertheless, the use of decentralized ID (DIDs) has not been understood well, and used as it should be.
- The use of domain or subdomain names can facilitate the easiness to make inter user token transfer. Instead of using the Stacks or Bitcoin addresses, the users can use the DID as the address to execute transactions.
- The use of domain or subdomain names can facilitate the easiness to make inter used non fungible token exchange or transfer. Instead of using the Stacks or Bitcoin addresses, the users can use the DID as the address to execute transactions.
- Users can use their DID to login into hundreds of available compatible Dapps, like for example in chat boxes, sharing of information, publications, etc. As a Single Sign On method, easier to use.
- Users can use their DIDs to login, create and share business process agreements, and deliverables, sign them, and inscribe them in the blockchain using the smart contracts.
- Probably, some business process agreements and deliverables, require that the participant users be identified by legal national IDs. Then a national attribution identity technology can be used by each one of the users, authorizing and linking it to the DID, as a proof of identity. This utility of proof of identity conforms to the requirement of KYC (Know Your Customer) imposed by some country governments. In this case, regulation, executed in a decentralized way, controlled by each user.
- Users could own a Single Sign On (SSO) technology to access any application.
- Users can use their did:web definitions as a web presentation landing page presenting their profile information. Individual web presence.
- Web marketplaces that recognize the use of did:web specification could facilitate the capture of user domain or subdomain names. These users will not require to re-enter profile information, as the did:web specification can be accessed through a .json file and entered to the application. This functionality increases the level of digital capital of the person or the organization.