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.

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?

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.

Ah, but this is pretty much an illusion on Facebook too, even if it is an expectation (remember the FB employee interview a bit ago where they mentioned saving EVERYTHING - which is plausibly more than what webmail does). You could have an interface that seemed to take back content if it made people feel better but it's ultimately bullshit.

My theory is that as people use the web, they'll begin to understand that sharing has it's inherent costs and no one is going to be able to protect you from them. In that way then, a more email-like service will make more sense to people.

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 -- 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.

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.

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.

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.

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.

Saving it, no. Sharing it, yes.

expect to be able to rescind it at any point in the future seems both unworkable

I agree

If you send an open message to X, you just aren't going to keep X from sharing that message with others.

-- There no real way around this. It's essentially the "problem" that DRM aimed to "solve". Thankfully, it couldn't. Only share things that are appropriate for a given friend or group of friends. This applies on Facebook or anywhere.

Reasons for a Facebook alternative:

* While counting on your friends to not share your data is going to be dicey regardless, at least your data is not automatically going to be sold. * Facebook changes it's interface and terms of service at it's discretion. You should be in charge of any changes to a sharing process. * Facebook has the stated aim of forcing everyone on the net to use a single identity. This is a rather Orwellian position that we should avoid (goes with the problem of FB changing their interface and terms of service whenever they wish).

About the FB identity, that's also very attractive to developers, and Appleseed should solve it somehow: if a website uses FB for user logins it gets almost-instant sign-up, user photo, user name, email (if requested) and access to a whole list of friends.

That's a pretty powerful incentive for websites to get integrated with Facebook.

It really seems like Facebook itself offers any more services as such than the regular web does. It just packages them more nicely - that isn't to say the packaging important, it's clearly very important.

1) people have to remember their service's endpoints, and the interface is getting cluttered with buttons for the major suppliers, and personally I have OpenID accounts by multiple endpoints, and even I had trouble logging in to StackOverflow.

There are 500 million people with an already existing Facebook account. Those people don't have to remember anything besides their Facebook login info.

2) On Facebook both the name and the email address is mandatory, and people want and do share their profile photo. Many people also have location info, which is quite useful for location-aware apps.

This is sparing you from asking (I'm sick and tired of filling my profile info on various sites I visit, but my Facebook account is up to date).

With OpenID you don't know what you're getting about that user.

3) You also get a little extra if you want: like the list of the user's friends, which is evil, but very attractive for me :)

So you're saying you're hoping just a little bit of Facebook's evil will come your way? Well, this indeed illustrates another reason to build a Facebook alternative... IE, No, I don't want a programming-answer site to tell my friends how much I like it, etc.

Maybe you haven't realized it, but when 2 people get connected on Facebook, that's public knowledge already that can be crawled.

If you're going to the normal route of getting your app integrated with Facebook, at least you're informing users that you need that access, and you also give them the option of blocking your app later.

If that's evil, then I'm all for evil ;)

[email protected]

My public profile then is:

developer.appleseedproject.org/michael.chisari

When I'm logged into my home node, I can go to any other Appleseed node, and "remote login" with my Appleseed identity. From there, it uses the same flow as OpenID, just in a more user-friendly fashion.

It's all quite painless for the end user.

One scheme would involve a system to merge multiple email and Facebook accounts into a single meta-view.

I'll be making an announcement when the time is right...

One of the ways that sites often scale is denormalization, so if they're generating each person's activity feed anyway there's no storage overhead. And I'm pretty sure that pgp encryption performance is measured in MB/s, so as javascript performance catches up the encryption time will be less of an issue.

Obviously even if everything is encrypted on the client side, what's to stop the server from sending down a broken javascript encryption mechanism, or javascript to send your messages in the clear? I don't think there's a good solution to this, but you could make some (optional) browser plugins to monitor outgoing requests, and that might be enough to keep server operators honest.

Even if someone overcame all of that, there are still a lot of features that just can't be built without the server having access to the data. But it's interesting to think about.

For distributing information to a group, you'd only need a single group private key, which you would send to each member using their public key. After that, you just encrypt the message with the group's public key.

If you want to kick someone out, you'd just start a new group in similar manner but excluding the someone you wanted to kick out. In this way, your group messages would only have to be encrypted once.

Each person would have a different group public key so there wouldn't be much more to it than this.

But all this is kind of overkill. You reasonably expect webmail provider will give you privacy right now just as reasonably you expect a locked door will keep your stuff safe even though a determined person can break either of those protections.

(and as said earlier, no magic technology is going to keep your friends from making stuff public)

"sure, don't trust me, do it on your own machine. I'll even give you the software..."