2 ms·
You have to think of it as writing a P2P app with no "trusted" server. Each client needs to be suspicious of all content created by other clients, and handle it
by kogir 15y ago
You have to think of it as writing a P2P app with no "trusted" server. Each client needs to be suspicious of all content created by other clients, and handle it accordingly. There are many services where a trusted server doesn't really add any value.
Consider for instance Facebook and Twitter. What if each user had full control over their own data:
Search: Each user would register a link to their data in a shared namespace so users could find each other. A single user could add/remove/edit their link, but only enumerate/search others.
Follow: The consumer traverses the link from the registry to the data and consumes it.
Friend: A asks to be B's friend by writing a request into a write-only namespace unique to B. B grants or denies access to protected data.
You get the idea. Nearly everything can be made to work with multiple clients that cooperate but don't trust each other. A trusted server isn't really required.
- bonaldi 15y agoNearly anything can be made to work, but in many cases it means jumping through a lot of hoops to get there. Without a trusted party you have to be much more suspicious of everything coming in, as you say, and that means coding additional verification, everywhere. For instance, with that model of friend requesting, there has to be some method of proving that A made the request to B. I can think of various ways of doing this (A signs their request, or A adds a duplicate outgoing request to a queue only they can write to, etc), but the point is that they're all much more overheard than doing it the traditional way. And that's just for a friend request. The big concern is that all this overheard will mount up enough to offset any of the other gains Firebase brings.