factor out IPFS

[nichoth]

consider

the scenario of a key leaking

With IPFS, redundancy is at the protocol level. So there is no way to be certain that a blob has been deleted after you request deletion.

This is in comparison to traditional blobs hosts.

We have a 'centralized' store for blobs. If you delete something, it is removed from the central store, and thus any new requests for it fail. Any of your friends who have already requested the blob would technically be able to keep it via their local storage.

local-first blob storage

• https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system
• https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
• https://web.dev/articles/origin-private-file-system
• https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate
• https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria

blob store

• [ ] need to create a blob store that evicts things based on how recently they have been looked at.

[nichoth]

We can use a more bespoke solution for directories/files here. That means we can organize such that every audience gets a unique symmetric key. Adding someone to an audience means adding a record to the audience with a map of

new user's device -> encrypted key

// audience
{
  members: {
    username: {
      deviceName: 'abc123',
      deviceName2: 'abc123',
      deviceName3: 'abc123'
    },
    username2: { /*...*/ }
  }
}

Removing someone from an audience would mean creating a new key and encrypting it to the new set of audience members.