Web3 - Linked Thoughts

[pepoospina]

• Register two remotes, one ethEvees, and one localEvees. Similar to how PolkadotCouncil remote is used on the Web3 Governance prototype.

• Modify the AppElements service and AppEkement interface to support an optional parameter for each element of the tree for the remoteId in which that element should be created. Use the default remote if the element does not have the remoteId set, but create that element in that remote if it is set.

• Modify the appElementsInit structure in LinkedThoughts so that it sets the remoteId of the blogSection to the ethRemote. Convert the structure into a function that receives the publicRemoteId and send it from the init.ts script.

• At this point the app should create the workspace skeleton in the localEvees and the blogSection in the ethEvees.

• Add the logic to use the remote of the guardianId perspective in the forkPerspective function of the EveesService as the remote in which fork a perspective, when the remoteId is not given as a parameter. This way, when AppManager forks a page, it will fork it in the remote of the section, and since the section is in ethEvees, the pages in the blog will also be created in ethEvees.

• At this point everything should work, except we need to check how to handle the ExploreServices.

---

IPFS Instability.

• Option 1, replace IPFS with Filecoin.
• Option 2, register two EntityRemotes, and persist entities both on IPFS and on the Server. This way if IPFS fails or is slow, the server will step in.

[sotous]

The following commit solves the IPFS instability problem, by changing the modules used in the IPFS connection submodule by a client instance, letting clear to the developers that any app that needs to use the IPFS connection should be provided with the HTTP connection parameters to the desired IPFS daemon.

Furthermore, it applies a client reset routine that clears out the queue caused by a bottleneck when many requests stay pending.

sotous/js-uprtcl@2594f25