What exactly is Fission?

Developers
1

I was going through the Fission docs to get a high level understanding of how Fission can help me as an app developer. I looked a bit into the Webnative SDK, WNFS, Fission Drive, and the Fission CLI and have some questions.

When you create a Fission Account, whether signing up on the web or using the command line as a developer, it creates a username and email address in our service database

  • What are Fission Services?

The Fission CLI and Webnative SDK are developer tools for interacting with Fission services

Taking a step back from the specifics and my own confusion (or ignorance), assuming I want to build an app:

  • What abstractions does fission give me?
  • What is the exact relationship between Fission and IPFS?
  • What are the limitations of using Fission?
  • What infrastructure do I rely on when using fission? Can I run the infra myself to retain full control?
  • What apps can be built on top of Fission today?

Any help or guidance would be appreciated

2

Hey - thanks for these questions, these are great. I want to first clarify that Fission is a protocol engineering team who are dedicated to

building the data, auth & compute primitives that enable true local-first edge applications. But we don’t get to the future alone. Our edge computing stack is already embedded into leading protocols, platforms and products.

( from fission.codes )

While we are obviously providing out technology as services directly to developers, our main line of business is in specifying and building the protocol building blocks themselves, and we do not currently have a typical SaaS offering for developer available as our main line of business. The current visible services we provide ( in particular drive.fission.codes and the related Fission auth application ) are instead intended as a working proof of concept for our technology.

I will try to provide some context below:

Fission currently provides identity and filesystem abstractions based on our use of Distributed Identity ( DIDs ), UCANs and the Webnative Filesystem.

Fission runs IPFS infrastructure and stores all data including both public and private ( encrypted ) data in IPFS. The Webnative Filesystem ( WNFS ) is a layer implemented on top of IPFS storage that provides a filesystem abstraction as well as encryption capabilities. When data is encrypted and stored in WNFS, we use the end-user’s own encryption keys associated with their DID to store their private data encrypted at rest in IPFS.

Side note: this is all possible via our use of the WebCrypto api and our use of non-exportable keys in the browser.

Fission has a future roadmap, so the lack of these features are limitations in the current offering:

  1. in the future app developers will be able to offer users of their apps the ability to register accounts directly with the app instead of the current implementation which utilizes a central Fission DID identity.
  2. we are working on a database abstraction for Fission apps that will augment the current filesystem abstraction. Developers will be able to interact with and query structured data in addition to being able to work with files and directories.
  3. we have plans to provide a “white box” solution to enable folks to run fission infrastructure themselves.

Currently when you use Fission you rely on Fission’s auth / drive / dashboard applications and backing services including IPFS infrastructure. If you create an app that uses fission, any users of your app will need to register for a Fission account, and your app will be published to and served by Fission’s web hosting infrastructure. There is currently no charge for this but this may change in the future.

As I mentioned before, we have plans to de-couple fission apps from fission’s own account system, and we have plans to provide a simple way to run the fission stack independently of Fission.

6 Likes
3

Thank you for answering in details, Jeff.

That clarifies a lot of my confusion.

Fission currently provides identity and filesystem abstractions based on our use of Distributed Identity ( DIDs ), UCANs and the Webnative Filesystem

Given the primacy of identity in apps, could you maybe verify my understanding of how you approach identity in Fission:

  • An identity is a key pair wrapped in a DID document
  • Key pairs are non-exportable keys from the browser
  • Each identity has super user access to “things it owns” (what constitutes ownership? encryption, signature, or something else)

How do I “connect” my identity on two devices if the keys are non-exportable?

The whitepaper mentions:

The Fission platform does not currently need to know that two keys are associated with the same underlying user, and is focused on correct-by-construction access regulated by having access to keys. This means that it has a very weak concept of “identity”, and is more focused on the delegation of capabilities between keys.

  • Would each device would have its own keypair wrapped in a DID?
  • On what layer would the delegation of capabilities happen for things like decryption (where you either have the key or not)? Is this where UCAN is used to encrypt using the second
  • If data is encrypted in WNFS using the key of my desktop device, how exactly can my linked mobile decrypt WNFS? (symmetric or asymmetric encryption?)

the current implementation which utilizes a central Fission DID identity.

Curious here too about how you use DIDs and how the central Fission DID identity relates to user DIDs.

If any of these questions are better answered by existing resources, feel free to link.

4

Yes. Today we’re only using did:key: which maps to RSA public keys in the browser in the identifier.
We even have DIDs per-app you’re using, since they’re hosted on different domains, and your WebCrypto keys are per-domain.

Signatures & encryption. If you want to prove to someone else that you own something (e.g. have write access), then it’s a bunch of signatures. More on the encryption below.
When you create an account at https://auth.fission.codes, this generates an RSA keypair and a did:key DID. This DID is then registered at our central Fission service.
When you link a new device, the new device generates another did:key RSA keypair (or ed25519 when on the CLI), and creates a UCAN that delegates all rights from your first DID to the second.

I think what Jeff is referring to when saying “central Fission DID identity” is that the fission services centrally store essentially the public keys of users “registered” at fission.
The user’s DIDs themselves are generated client-side and non-extractable.
What’s confusing is that the central Fission service also has a DID, but that exists only to sign messages specifically “meant to be consumed by the Fission service”.

In the WNFS case, UCANs are only used for write access.
Encryption keys are used for read access. If you have the key to decrypt a file/directory at some point in time, you have read access.
If you want to delegate that read access, you share the key to some other device using a secure key exchange protocol (AWAKE).
This requires a synchronous protocol between peers. There’s also an async way to share (currently only read) access between peers, which is based on encrypting secrets for specific public keys, our shared private files.

1 Like
5

These are all “user DIDs”. The keys are held by the user.

Some of the confusion is that identity/account and DID are not the same thing. eG you need to add other info like perhaps a username or an email address to start having an “identity” and DIDs don’t do this. With UCAN they provide the auth layer of passwordless logins.

We generate a Fission account and give permission to user DIDs. Then each DID delegates permission to other DIDs with signed proofs.

The DAGHouse team put a server in the mix and are exploring a DID that is more like an account and has sub DIDs. We’ll be digging into this in the UCAN working group to come up with more patterns and interop.

For devs, they’ll use Fission’s Webnative SDK and create DIDs for users — instead of a username and password. So the feature is passwordless login.

1 Like