Selective sharing and user blocking?

[Michael-S]

I realize I may be asking for the sun, moon, and stars here, but it would spectacular if Fritter had the option of selectively sharing content and blocking users. Right now, of course, Fritter has the model that I don't have to follow others but anyone that follows anyone else following me can also find and follow me.

My idea for this is almost certainly either fundamentally flawed or else already under consideration. But I figure I'll share it anyway. Selective sharing and user blocking:

1. 'Public' Fritter sharing works as it does today.
2. Fritter accounts generate a short-lived symmetric key for decrypting their selectively shared content.
3. Fritter accounts publish one message per each permitted follower with that symmetric key encrypted using the follower's public key. Other followers read something in the key-distribution message to indicate it's not meant for them and ignore it. OR the account publishes one giant message that is some kind of delimited string of follower public keys and follower public key encrypted symmetric keys.
4. Then the account publishes the actual content, and the followers use the symmetric key to decrypt. Anyone can download and anyone can even help distribute the person's content using dat, but without the symmetric key the data is useless.
5. When a new follower is added, the Fritter account just distributes their symmetric key to new followers. When a follower is removed, the Fritter account generates and distributes a new symmetric key that will be used for all subsequent posts.
6. When the Fritter account wants to share a message with only a few followers, a new symmetric key is generated and shared with those recipients. Then when the user returns to sharing with their entire set of followers, a new symmetric key is generated and shared again. If you follow someone that publishes a message but has not distributed the new symmetric key to you, your Fritter client ignores the message and you never see it in your "feed".

Thoughts? I mean the ugly side is that a busy account with lots of activity would be generating thousands of tiny messages for key exchanges just to post "OMG the dog just stole a slice of pizza off the table!" But despite the high volume of symmetric key exchange messages the key exchange message size would be tiny.

I ask for this because I think a p2p social network is wonderful, but me and most of the people I know want a p2p Facebook/Instagram, not a p2p Twitter.

[pfrazee]

SSB does something similar for private messages, see https://github.com/auditdrivencrypto/private-box. Basically when you see one of these encrypted messages, you try to decrypt. If you're a recipient, decryption will succeed. Otherwise, you can just ignore it. (IIRC it has up to 8 recipients so you try 8 times.)

I think you're right that encryption schemes are needed because private sharing is a huge use-case. I don't have the resources to dedicate to that yet but I welcome folks to try out all kinds of schemes!

[Michael-S]

Thank you for your response. I'll play around with the idea a bit - but don't hold your breath.

[RangerMauve]

I think that this would be a lot easier to do with this change in WebDB

[Michael-S]

I don't follow how that change would facilitate this feature. Would you please explain in a little more detail?

[RangerMauve]

As pfrazee mentioned, you could use private-box to encrypt messages so that only the people the message are destined for can decrypt and read them.

WebDB, the thing that Fritter uses for indexing posts currently only support JSON, so you'd need a way to attempt to decrypt messages before they get indexed with WebDB.

The change I linked to could be used in combination with a file extension for encrypted messages to have WebDB automatically attempt to run the decryption on them.

After that you'd just need to add something for tracking people's public keys for private-box (probably a field in the profile.json?) and something for generating these private messages.

[Michael-S]

I see, thanks for the answer. There is enough of dat and Fritter's architecture I don't grasp that my own mental model of the solution was at a very high level. The change you're describing is, as far as I can tell, more on the order of layering additional features and behavior on top of what Fritter already does. My rough, hand-wavy idea was to mess around with Fritter's guts.

(Edit: Sorry, I should have clarified. I'll try to run with your ideas, if it's possible to do this without rewriting parts that already exist it would be better. I'm emphatically not trying to say, "I see what your point is but am going to ignore it.")

[RangerMauve]

Well, you could simplify it further, actually. You can just encrypt the text field within the messages with secret-box and add a new field marking it as encrypted.

Then you'd just need to track people's public keys for secret-box from their profile.json, and would need to modify the fritter UI for rendering the message.

You'd still have the metadata on when it was posted and what the post might be replying to, though.

[Michael-S]

It would be nicer if the metadata could be inside the encrypted payload. But I'm in serious danger of planning feature enhancement 42 when feature 1 never gets written. Let me fork this and start playing games.