Aral Balkan

Mastodon icon RSS feed icon P2P network icon

Hypha Spike: Persistence 1

Note: Unlike previous spikes, I’m leaving this spike in a non-functional state and instead starting from scratch on the main project. See post-mortem

Source

Scope

Following on from Hypha Spike: Multiwriter 2 this spike aims to:

Design

Screenshot of the flow to be implemented in this spike. The details are explained in the text below.

Implementing persistance and getting closer to the actual flow.

  1. Domain registration + hosting setup (out of scope, although see Hypha Spike: Deployment 1)

  2. Origin node setup: an uninitialised always-on node is hit: the setup page is delivered. In browser (and, later, also via native app), person chooses a generated Diceware passphrase. The node that the person is using becomes the origin node.

  3. Origin node replicates to the unprivileged always-on node via WebSocket. At this point the always-on node is initialised and set to replicate that particular database only.

  4. The person sees themselves as signed in and can post entries. (For the purposes of this spike, simple text-only public posts – just so we have some data and can see things replicate.)

  5. On some other node (browser or native), person accesses the domain. They can see the public posts as we set up a read-only local database and replicate them. We know which database to replicate based on a Dat-DNS lookup via the .well-known/dat location on the domain of the always-on node. See security note 1.

    They do not see the positing interface. Instead, they see a passphrase field (not shown in above whiteboard sketch) and a sign in button. Entering a passphrase creates the deterministic keys and proceeds to request authorisation via the secure ephemeral messaging channel. The person is asked to authorise the request from an existing node (e.g., the browser(/native app) they set up from). _ out of scope for this spike._

  6. On a previously-authorised node (e.g., the origin node), the person approves the authorisation request.

  7. On the newly-authorised node, the person sees the posting interface and can now write to the database.

Iteration plan

  1. ✔ (tag) Implement random-access-idb in the browser node.
  2. ✔ (tag)Implement random-access-file in the always-on node.
  3. Update interface and flow according to the design notes above.

Future plans

Upcoming spikes

Development notes

Post-mortem

Working on this spike has made a couple of things clear:

Security considerations

  1. Regarding design step 5: Remember that the always-on node is untrusted and unprivileged. We could easily set it up so that it returns the Dat URL in the rendered source but we won’t be doing that. The unprivileged node will return unaltered source that we will verify using subresource integrity (out of scope for this spike). We will also implement trusted third-party audits of the source (this could, for example, be handled by a browser extension that compares the hashes received as well as the hash of the source code with the trusted hashes from the source code repository).

Other: See Hypha Spike: Multiwriter 2

Reference

Also see Hypha Spike: Multiwriter 2 Reference