Facebook-style friend request challenges in decentralized network

Interesting discussion in slack about the challenges of implementing Facebook style friend requests in a decentralized network:

dimitrovskif [6:44 AM]
I designed my own decentralized protocol and found out about blockstack, so I quit

@ryan [6:44 AM]
oh no haha
would love to hear about it
maybe you can build a decentralized layer on top of blockstack
our goal is to help many developers build decentralized apps, many with their own protocols

dimitrovskif [6:45 AM]
The idea was to serve JS single-page apps that use a decentralized DB via a public API in the global namespace
And everything was supposed to be public and forkable, all the apps’ source code
There were some limitations, most apps need centralized data source - ex. news and weather

@ryan [6:46 AM]
very cool
yeah news and weather do
although the key is to make a system that can take in data feeds from any news or weather api (commoditizing the data sources) (edited)

dimitrovskif [6:47 AM]
forums and chat are easy to do with end-to-end encryption
however facebook-style friend requests can be hard
since the code and the DB is public and distributed among all the nodes

@mwilcox [6:47 AM]
aren’t they just another type of message?

dimitrovskif [6:48 AM]
yeah but you have to send a message to everybody
it’s like having a group chat with whole fb

@mwilcox [6:48 AM]

dimitrovskif [6:48 AM]
and only the person receiving the friend request can decrypt it

dimitrovskif [6:48 AM]
how can you send a friend request in a public DB anonymously?

@mwilcox [6:49 AM]
isn’t it just a direct message encrypted against a public key that says please add my public key to your address book? (edited)
why does the friend list need to be public I guess is what I’m asking

dimitrovskif [6:49 AM]
even direct messages are tricky

@mwilcox [6:49 AM]
yeah, you have a chicken & egg problem

dimitrovskif [6:49 AM]
the content itself can be encrypted end to end

@ryan [6:49 AM]
@dimitrovskif @mwilcox you either need everyone to have a personal API that’s always online OR you need them to have a push notification server that’s always online (edited)

dimitrovskif [6:50 AM]
but the sender/recepient pair has to be known

@ryan [6:50 AM]
store and forward of some kind
the notifications are the most annoying part imo

@mwilcox [6:51 AM]
the way that we address these types of problems is encrypted public block devices that you pub/sub
(so the node doesn’t have to be online at the time you send the message)
you could do the same on ipfs

@ryan [6:52 AM]
yeah it doesn’t but something does
you have to delegate to something to store and then forward to the node

@mwilcox [6:53 AM]
yep. if you encrypt you can delegate
you just need an addressing scheme to look for new messages
that’s the hard part!

@muneeb [6:56 AM]
pub/sub can work
protection against spam/sybils is an issue

@mwilcox [6:58 AM]
yeah there are a bunch of different ways of approaching it… changes depending on your use case
I don’t believe in a universal solution for it, since it all depends on trust / performance requirements