dSocial development is underway. As you will see in the “dsocial-web” repo (https://github.com/getdsocial/dsocial-web), we have published two files to kick things off:
- dweb-app-manifest.json
- chain-manifest.json
These two files are used by the PeepsID authenticator to verify that the app executing actions for dSocial`s ARISEN-based smart contract, is indeed, the official dSocial application. You can learn more about ARISEN`s AATP protocol, its Manifest Specification and its Ricardian Specification, at the following links:
- https://github.com/arisenio/arisen-authentication-transport-protocol
- https://github.com/arisenio/manifest-spec
- https://github.com/arisenio/ricardian-spec
NOTE: These specifications were forked from EOSIO and repurposed to work with DWEB rather than HTTP.
The manifest files above are required by all dWeb-based applications that utilize an AATP-ready authenticator like PeepsID for signing transactions. Keep in mind that the location of the dweb-app-manifest.json file, along with a SHA256 checksum of the file, are stored alongside the “dsocial” contract on the ARISEN chain (using the “add.manifest” action via the “arisen.assert” contract [https://github.com/arisenio/arisen.assert]). This ultimately allows authenticators to verify that the application sending the requests, is indeed using the domain that it says that it is. This is to prevent application phishing on the network, where one application could pretend to be another, by simply sending a request that contains a false “returnUrl”. AATP-ready authenticators check the “dweb-app-manifest.json” file at the domain provided within the actual signature request payload (the returnUrl), looks for the dweb-app-manifest.json file at the domain provided in the returnUrl (in the root of the domain) and checks if the checksum of the manifest registered on ARISEN, matches the checksum of the current manifest file on the domain. If so, the authenticator is able to verify that the domain making the request, is indeed the same domain that registered the manifest. Afterwards, the authenticator will check the chain-manifest.json file, for the contracts and their associated actions that the requesting application should be allowed to request signatures for, from the authenticator.
You will notice that in the chain-manifests.json file, that all of dSocial`s smart contract-based actions, like post, comment and others are laid out nicely. That should give you a nice preview into tomorrow`s post, where we will begin debuting the dSocial smart contract, piece by piece, along with the Ricardian descriptions for each action. If you`re lost, I suggest reading the AATP paper, and the Manifest/Ricardian specifications above, so that you can get a full understanding of how important these two files are and why they exist.
You can expect a new development update every single day from here on out, as we take you through the play-by-play of building a dWeb-based application.
TOMORROW: The roll out of dSocial`s smart contract and its associated Ricardian descriptions.
Peeps Development Team
