3 ms·
First off, your feed won't provide a full copy of your data, just a summary and a link. Other protocols may not work that way, though, but that's how Appleseed
by michaelchisari 16y ago
First off, your feed won't provide a full copy of your data, just a summary and a link. Other protocols may not work that way, though, but that's how Appleseed's protocol works. If access is rescinded, that user loses access to view that data. If I post a journal update or a photo, and it shows up in your feed, and then I restrict access to it, if your feed doesn't properly delete the entry, then you can still see the summary or the thumbnail, but clicking on it results in an access denied error.
Well, let's focus on your premise: This is all based on a node turning evil. That's a very big problem, and one not easily solved.
There is a basic issue here, in that users, when they trust other users, they also, on some level, trust the that user's community (node). I'm open to suggestions on how to mitigate that.
With social networking, there is always a level of trust that has to be human-based, not tech-based. But tools can be used to help humans determine trust.
Appleseed has node control, which means that administrators can "block" whole nodes if they're behaving badly. This usually means spam, but it can also mean if a node is acting in bad faith (ie, it's revealed that AppleBook is selling non-local user data), or if they're abusing the protocol. That can act as a certain type of social "shunning" on a node-to-node basis.
Admins can also "trust" nodes, which means you inherit their block list. This means, theoretically, if a node goes bad, and some nodes realize this, it'll propagate through the Appleseed network until that node is isolated.
I think there are other approaches, and some we haven't thought up yet, but one thing I'm most interested in is social pressure, and how it can easily be applied to bad nodes.
I think encryption is interesting, but I think we'll actually have to move into the browser space in order to have a reasonable UX.
- mayank 16y ago> This usually means spam, but it can also mean if a node is acting in bad faith (ie, it's revealed that AppleBook is selling non-local user data), or if they're abusing the protocol. That can act as a certain type of social "shunning" on a node-to-node basis. There are interesting, open theoretical computer science questions that determine how effective such an approach can be, and how susceptible it is to attack. Without a theoretical understanding of how your reputation system works, how do you propose to solve the spam and "evil" problem? In other words, if we invest heavily (time and money) in this, how do we know that it won't eventually be overrun by spam after being mastered by a clever (or lucky) hacker? If you haven't already, you should check out: http://en.wikipedia.org/wiki/Byzantine_fault_tolerance http://en.wikipedia.org/wiki/Byzantine_fault_tolerance -- the Byzantine agreement problem, which deals with a distributed system agreeing on a global decision (substitute "failure" with "evil"). These are not trivial problems to solve, and if you intend on scaling, I hope you have good solutions to them. Distributed systems are notoriously hard to understand and maintain; it sounds very nice to propose a new distributed system, but it's hard for a hacker to accept your solution until I have some theoretical assurance about its security model.
- michaelchisari 16y agoI'll remind you that what you're addressing here is the protocol, which is not dependent on Appleseed. Appleseed is the platform, and is basically protocol agnostic. There are a lot of projects working together on a common protocol, including people from the W3C, and we're all aware of these issues. Appleseed is doing it's part to create a flexible framework that is easily administered and updated, so that nodes within the network can be moved to a new protocol when exploits are found. But this is in no way a problem that Appleseed will be solving alone.
- mdasen 16y agoWonderful. The Diaspora group had been promising end-to-end encryption without seeming to know the problem. The remaining question I have is: while the feed provides a link/summary, what's preventing a node from following that link and then caching/storing that data? You've come up with a nice way of propagating block lists and kudos for addressing the problem. However, with Facebook, I only have to worry about Facebook behaving badly. I don't have to worry about multiple companies and different bad behavior. Plus, sometimes bad behavior can become public much later. Let's say that I operate Applebook. I'm running a nice Appleseed server that has some users. I decide to start storing the data from other nodes. Maybe I'm even doing it for practical reasons like performance or as a service to my users. Then 5 years down the line, my fortunes take a turn for the worse. I decide to go evil! Sure, maybe the second I turn evil it gets propagated out fast and I can't get access to any future data. However, I still have all that past data! And this is a concern with Facebook as well. They could turn evil some day and betray us all. However, it's one company to worry about rather than dozens or more. -- Also, as an aside, sometimes the summaries might contain the information people want deleted. If you have a 140 character status update Twitter-style, there isn't much of a summary to be made. Right now, we're used to being allowed to remove things from social networks. Unlike email, it's communication that we can take back. Wall posts, status updates, photos, etc. can be deleted. If I email you a photo, it's always there for you. In some ways, a distributed social network is more like email. Once you've sent it out to your friends, it can't really be taken back. That's very different from Facebook. With Facebook, users expect to be able to remove content at any time and it's inaccessible to other users (unless they decided to copy/paste or save it in another way). The question is: how many people would prefer this more email-like system? The advantage is that one wouldn't be beholden to a central service like Facebook or Twitter. Users have been skittish about privacy anytime Facebook changes something. How much of that is posturing and how much of it is users who would discontinue using it if they thought they couldn't remove things from the view of others?
- michaelchisari 16y agoThey could turn evil some day and betray us all. If an Appleseed node turns evil, they'll probably take the data of, maybe, 100,000 or a million users with them. When Facebook turns evil (some would say saying "when" isn't necessary), 500 million people's data goes down. One of the things that's kept Facebook free of social pressure in terms of acting evil, is that the walled garden approach means that people can't leave without losing their social network. Appleseed (and distributed social networking) at least provides a certain competition, because if a node acts up, users can leave that node, go to another node, and reconnect with their friends. It won't be totally painless (at first anyways), but that's pressure that Facebook simply does not feel at this point, and that has a very negative effect on it's behavior. The question is: how many people would prefer this more email-like system? I'll be the first to admit that a centralized system holds advantages over a decentralized one (and vice versa). A lot of these issues, we may not even know the full extent of until we see heavy use. This is pretty new territory, and I'm open to any suggestions. It's the big reason why I rewrote Appleseed to be extremely flexible, to use pervasive hooks and an MVC model, and to be protocol agnostic. Also, why Appleseed has one-click server upgrades and other ease-of-administration features. There's some really solid work being done on protocol development, but I think we all need to be honest that the first steps out of the gate are gonna be rocky. Hopefully Appleseed can adapt quickly enough until distributed social networking matures.
- joe_the_user 16y agoIf access is rescinded, that user loses access to view that data. And if the user has a script that saves all the data they momentarily had access to, what happens? I mean, I'd do that since I expect continued access to any data I get. I don't think that makes me "evil". The whole thing seem ridiculous. If you have 500 different messages for 500 different people, send them each an encrypted email and be done with it. If you're sending the same message to 500 people, the chances that you'll be able to rescind it seem negligible. I mean, for 500 people not to share a message either 1. It's very boring enough they wouldn't bother, 2. They are really tight with you somehow, 3. They're part of a very tight, well managed organization. But none of this can be controlled by software. If a node is just supplying information transport, that is different and encryption works and is intended for that situation. But thinking there's a way to send information to your friends to read and somehow force them to keep it secret seems ten times as preposterous of earlier "trusted platform" end-to-end DRM schemes. Am I missing something? Tell me.
- michaelchisari 16y agoAnd if the user has a script that saves all the data There's no algorithm yet for how to deal with friends who are dedicated, untrustworthy jerks. Someone out there, somewhere, is working on it, but Appleseed is focused on providing tools for users to determine how they group their friends based on trust, but if that trust is broken, there's not much that can be done (at this point), except to remove that person's access, and no longer trust them.
- joe_the_user 16y agoI don't actually think that saving an email or message or whatever makes me untrustworthy. A scheme where one could send a message to someone and expect to be able to rescind it at any point in the future seems both unworkable and not really the way I expect people, "friends", to relate to me.
- michaelchisari 16y agoI don't actually think that saving an email or message or whatever makes me untrustworthy. Saving it, no. Sharing it, yes. expect to be able to rescind it at any point in the future seems both unworkable I agree