I can go into whatever depth you want
That said, it’s early and we don’t have the relevant code yet, so this is still hypothetical, and we are researching options (which is to say that I have a plan and a couple backups, but haven’t executed on them yet).
Since we’re being super pragmatic, and are happy to give people the actual keys but have FISSION’s centralized services act as signal amplification, one option is to leverage our gateway to centralize the lookup of FISSION user’s IPNS checks (we’re writing the records, so we’re sure that we have the most recent copy). If we wanted to, we could plug that into ENS for similar effect, but IPNS is the main supported format now. In all cases, we update the user’s root on push. Because CIDs can contain named links, we can namespace portions of their DAG. I’m getting ahead of myself now, read more below…
I personally don’t love the per-app model (
mymusic.example.com). I would go further: only update the user’s root, and use subdirectories for everything else. Part of our strategy is using a domain name as a human-readable identity, and subdomains as sub-identities (e.g. in an org). The other option for subdomains is to use them as symlinks deeper into the DAG, but for consistency this seems like more work to me than having a consistent subdirectory path. But hey, that’s me Totally open to other opinions on the above. Thoughts?
TXT https://brookie.me/ —>
Everything under that top CID (or IPNS record) gets namespaced:
Qm...Jd/bookarks (i.e. shortcuts, mainly not in your own tree)
These can further break down:
[challenge being that doing unions between collections requires runtime compute at least the first time]
Multi-user directories have the challenge of needing to update two or more DAG roots. A couple solutions:
- DNS Link
- Separate root for the shared data
- Give everyone involved write access to the root via DNS or IPNS
- e.g. could be facilitated by ENS
Private data contains the same data links, but with the DAG node being encrypted for the allowed parties, which can decrypt and follow the edge to the next encrypted node.
Retrieval is trivial – follow the named links
Yes, updating deep files is more challenging, but as you mention there are ways of patching DAGs and getting the new roots. I anticipate some kind of funkiness to pop up somewhere, but we can happily abstract over these tools and create high level lenses and whatnot (i.e. standard abstractions for updating immutable data λ something something “this one weird trick: profunctor optics”)