DNS Automation for IPFS

Developers
1

Just went through the slides from @expede’s IPFS talk, great slides! I noticed that you’ll be doing IPFS DNSLink on https://yourname.fission.tools, which is awesome! Will there be an API for that as well?

I’m currently exploring the different possibilities of using IPFS as application storage. The idea I had to integrate the Fission IPFS API goes as follows:

  1. App uploads data to the Fission API
  2. App gets back CID and stores that on the Fission domain using the Fission DNSLink API
  3. App retrieves stored data by somehow resolving the DNSLink (using personal IPFS or Fission API)

Is that the general idea you’re aiming for?
Thanks!

2

@expede will have more details, but yes we will automate DNS. First for subdomains and then for your own domain.

Tying this to username — a bit like OpenID, username@example.com — or per-app, like diffuse@username.example.com — might be different ways to have the user get back to their stuff.

Hmm. Thinking some more. For the user, remembering mymusic.example.com — which you can resolve a CID from, which can be a folder filled with audio files — is probably easiest.

And that’s assuming unencrypted mode, of course!

Tell us more about how you WANT it to work!

2 Likes
3

I like the mymusic.example.com folder idea!

It’s not entirely clear to me how this would work, because this is so new.
But in any case, here’s what I got:

  • I know that username@example.com can only resolve (ie. dnslink) to one CID, so I assume this will resolve to a directory.
  • I would like to upload files using the API that will end up in that directory.
  • I would like to retrieve a specific file from this directory (I assume this is possible with IPFS using a combination ipfs add and ipfs object patch add-link :thinking:)
4

I can go into whatever depth you want :stuck_out_tongue:

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 :woman_shrugging: Totally open to other opinions on the above. Thoughts?

Anyhow…

TXT https://brookie.me/ —> QmSrPmbaUKA3ZodhzPWZnpFgcPMFWF4QsxXbkWfEptTBJd

Everything under that top CID (or IPNS record) gets namespaced:

  • Qm...Jd/files (i.e. ~/Documents)
  • Qm...Jd/data (i.e. ~/Application\ Support)
  • Qm...Jd/code (i.e. /usr/local/bin)
  • Qm...Jd/bookarks (i.e. shortcuts, mainly not in your own tree)

These can further break down:

  • Qm...Jd/files/images/collection/location/vancouver
  • Qm...Jd/files/images/collection/event/run_evm
    [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
    • Point to a DNS record
  • IPNS
    • Point to an IPNS record
  • 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 :rocket:

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 :stuck_out_tongue: λ something something “this one weird trick: profunctor optics”)

1 Like
5

I did not mean this as a per-app model – I meant it as a user-specific identifier, in the form of a subdomain. So, I might use boris.diffuse.sh (provided as a convenience by the app) or music.bmann.ca or music.boris.fission.tools (created by me as a convenience that points to a hash – I guess kind of like favoriting a folder).

It was me thinking about a way to do pseudonymous “login” with the user just having to remember a domain name, but realistically having an actual user login is way more useful.

6

I’m all for the user-specific identifier steven.fission.tools!

Everything under that top CID (or IPNS record) gets namespaced

Cool! Exactly what I was hoping for :pray:

I anticipate some kind of funkiness to pop up somewhere

For sure. For example, I was under the assumption that IPNS is currently really slow (1+ minute lookups).

profunctor optics

You lost me there … jk :stuck_out_tongue_winking_eye:

I can’t say much about the DAG stuff, because I’m not familiar with it. I’ll try to learn about it soon so I can help out a bit if time permits. In any case, good luck! This plan sounds pretty solid with enough backup options :ok_hand: I, cannot wait, to implement this in Diffuse :raised_hands:

7

It’s extremely uneven. If we control the web2 gateway that people are accessing IPNS through for both reads and writes, then it’s as fast as a centralized server, with the advantage that it talks to the rest of the network. Is this centralization? Yes, but an open centralization. Our strategy is “progressive decentralization”, giving speed boosts now, but leaving it fully open and compatible with other decentralized services.

1 Like
8

Awyiss! I’m really excited to see what you do with it :tada:

9

Is there a way to make browsers isolate security/storage/service workers for multiple apps hosted as subdirectories? I was under the impression that subdomains were needed for that and that that was why things were moving to base32 in ipfs.

These are all high-level impressions though, my knowledge of browser security is very limited.

I also think the sub-subdomain thing is a little ugly and possibly confusing to users, and all isolation things being equal I’d prefer that too.

2 Likes
10

Subdirectories on the IPFS storage side.

The app itself is MyCoolApp.com, that you login to and your Fission Drive files are available to that app — you auth with the app that gets access to /Apps/MyCoolApp and then maybe it also gets access to /Photos

We need to integrate identities with the Fission platform and then both users and apps can have a pretty great experience.

1 Like
11

Yeah, what Boris said :point_up_2:

The model is inverted from how webapps work today — think more like an native iOS app. Everything is encrypted and only the user can see it in plaintext.

By default, all data requests go through the SDK. Requests kicked off by the user, essentially fun the app’s functions over the user’s data. This is temporary access to clear files as a data stream.

If an app wants longer access, they can request access to some path, which the user may grant via the symmetric key. The app can then see everything below that level (recursively encrypted with keys at each directory level, similar to peergos.org). Multiple apps may have access to the music directory, for instance. If access is revoked, the SDK re-encrypts each directory with a new symmetric key, and does key exchange with still-authorized apps/peers.

Does that make sense?

1 Like