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]
why?
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