Users can then create multiple personally-owned eventlog OrbitDB databases, each being what we call "a perspective", where they basically can update the latest head commit of their "branch" of the Wiki. Each eventlog can be updated by a single user.
Besides this, there are multiple context stores, where a user can register one of their perspectives as being related to a given context, where the context is a simple string. This helps the UI show the different perspectives of one Wiki. There is one context store for each string, and any user can add a perspective they own to the store.
The implementation uses OrbtiDB js libraries and js-ipfs to create and replicate these databases on the frontend application. It will soon be modified to use go-ipfs over http as the js-ipfs "router".
The work
In summary, we need to set up:
[x] Orbitdb pinner
[x] Data backup and recovery process
[x] IPFS pinner
[ ] OrbitDB to Ethereum address map server
Details
As the final task of the development of the OrbitDB infrastructure for our Wiki, we need to set up a supporting infrastructure for our app, on AWS, that pins all the OrbitDB databases and IPFS content created in it and is used as the default store when reading the content from the Wiki.
The idea is to have the experience as fast a possible for casual visitors of the page who might not even be logged in to OrbitDB with their ethereum account. And to make sure all content is available even if the content creator goes offline. We have seen 3box has one pinner and colony has another.
We also have a single IPFS gateway right now deployed on AWS and we'd like to review it and consider improving it to an IPFS Cluster if deemed necessary and useful.
Besides this, we will need to deploy or reuse an Etherum to OrbitDB mapping server, similar to, or directly reusing (https://github.com/3box/3box-address-server), to keep track of which Ethereum address corresponds to one OrbitDB address. We will also be using OrbitDB using polkadot.js as an identity provider soon, so this server should be compatible with Polkadot addresses too.
Finally, we will need a data backup and recovery process in place that backup IPFS objects and OrbitDB stores and is able to reload them if needed.
The work would probably be done on one or more AWS instances appropriately dimensioned for this use case. The expected load and traffic of the app will likely be small, with a few contemporary users at once most of the time.
Overview
We have developed, with the help of @tabcat, an OrbitDB Service Provider for our GIT-like Wiki (prototype at https://eth.intercreativity.io needs metamask on rinkeby), that uses eth addresses as the identity provider. You can see the code here.
Users can then create multiple personally-owned
eventlog
OrbitDB databases, each being what we call "a perspective", where they basically can update the latest head commit of their "branch" of the Wiki. Eacheventlog
can be updated by a single user.Besides this, there are multiple context stores, where a user can register one of their perspectives as being related to a given context, where the context is a simple string. This helps the UI show the different perspectives of one Wiki. There is one context store for each string, and any user can add a perspective they own to the store.
The implementation uses OrbtiDB js libraries and js-ipfs to create and replicate these databases on the frontend application. It will soon be modified to use go-ipfs over http as the js-ipfs "router".
The work
In summary, we need to set up:
Details
As the final task of the development of the OrbitDB infrastructure for our Wiki, we need to set up a supporting infrastructure for our app, on AWS, that pins all the OrbitDB databases and IPFS content created in it and is used as the default store when reading the content from the Wiki.
The idea is to have the experience as fast a possible for casual visitors of the page who might not even be logged in to OrbitDB with their ethereum account. And to make sure all content is available even if the content creator goes offline. We have seen 3box has one pinner and colony has another.
We also have a single IPFS gateway right now deployed on AWS and we'd like to review it and consider improving it to an IPFS Cluster if deemed necessary and useful.
Besides this, we will need to deploy or reuse an Etherum to OrbitDB mapping server, similar to, or directly reusing (https://github.com/3box/3box-address-server), to keep track of which Ethereum address corresponds to one OrbitDB address. We will also be using OrbitDB using polkadot.js as an identity provider soon, so this server should be compatible with Polkadot addresses too.
Finally, we will need a data backup and recovery process in place that backup IPFS objects and OrbitDB stores and is able to reload them if needed.
The work would probably be done on one or more AWS instances appropriately dimensioned for this use case. The expected load and traffic of the app will likely be small, with a few contemporary users at once most of the time.