Share files in messages

[nikolaiwarner]

It would be excellent to be able to drag and drop, copy and paste, or select from a dialog files that could be sent to the channel connected to messages.

I'm not sure where cabal core stands at the moment with implementing files connected to messages but it would be super useful.

[hackergrrl]

I think it would be really easy to add a message type file where a user could link to an HTTP or DAT url, and have clients fetch it (if desired).

[cblgh]

i was thinking about this for some reason and wanted to chime in. i think that keeping binary blobs outside of the chat database is important.

at the same time i think it would be very interesting to figure out a good solution for how we can support loading image-based avatars and custom emojis, as well as custom blocklists per cabal-club/cabal-cli#41 or even settings/styles.

ssb separates it nicely with its blobs store, maybe we can use a set of hypercores for our blob stores somehow? do we have one hypercore per blob-message-type? that way you could create a view over the set of custom emojis in the cabal and share them between different cabals, while separating them from avatar images or blocklists.

so the blob types could be

message-type: blob
blob-type: emoji|blocklist|generic

it's a bit off, but i wanted to share my thoughts while they were floating around 🌊 ⛵️

[hackergrrl]

hyperdb's neat trick is that each user has two feeds:

1. their message feed (all messages to a chat, for example)
2. a content feed

The content feed stores all of the binary blobs, but default replication only syncs the message feeds of users. This way you can have entries in your message feed that reference an entry in someone's content feed (e.g. pubkey@sequence) and that peer could request that entry from surrounding peers (or the creator) directly.

SSB's trick is to automatically share blobs within a peer radius (ask all peers to store this blob for them). Some can/will say no, but it generally helps seed that blob around the network. I like this approach because it allows content to be addressed by hash instead of owner, meaning the same data from multiple authors won't be duplicated. It also decouples us from hypercore, which seems like overkill for moving binary blobs around.

[todrobbins]

@nikolaiwarner any update on the file sharing branch? how can we help?