Help fund an open source Facebook alternative: Appleseed(indiegogo.com)
indiegogo.com
Help fund an open source Facebook alternative: Appleseed
http://indiegogo.com/Open-Source-Social-Networking
9 comments
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.
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.
Wonderful. 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?
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?
They 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.
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.
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).
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.
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.
> 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 -- 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.
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.
I'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.
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.
If 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.
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.
And 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.
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.
I 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.
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.
I 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
Saving it, no. Sharing it, yes.
expect to be able to rescind it at any point in the future seems both unworkable
I agree
I don't think you'll get that kind of security in this space-time continuum...
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.
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.
I'm glad I'm not the only person who thinks this. Friendship is not an idempotent operation. Facebook connects up hundreds of millions of people and makes it extremely simple for them to share information. It's a social internet. To make any kind of attempt to preserve privacy is practically oxymoronic.
Then why bother with a Facebook alternative?
Good question.
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).
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).
Yes, I've been reading the other comments, and a distributed network would have some advantages, but also disadvantages, a strong analogy being email and smtp.
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.
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.
Well,
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 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...
For identity, why not use OpenId?
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.
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.
I do not like OpenID:
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 :)
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 :)
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.
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.
I'm having trouble parsing that.
It's like you went bezerk on reading the word "evil".
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 ;)
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 ;)
Appleseed uses identities that look just like an email address. For instance, mine is:
[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.
[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.
I was thinking of a similar thing the other day. Could one make an easy-enough-to-use public-key encrypted social network?
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.
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.
Actually,
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)
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)
For example, clipperz en-/decrypts in the browser and not on the server.
Ah but while the browser may be running client side, it hardly seems like the piece of software I'd want to trust to do my encryption given that it is designed with many hooks to allow servers to do stuff.
"sure, don't trust me, do it on your own machine. I'll even give you the software..."
"sure, don't trust me, do it on your own machine. I'll even give you the software..."
"Install your Appleseed node ($1,000 minimum)
Free installation of Appleseed on your servers for any Appleseed node with less than 1,000 users."
Is it FOSS or not? It sure doesn't sound like it is.
"We've already accomplished much of what we set out to do"
Then why are you asking for $10k?
There's a lot of text on that page that directly contradicts other text on the page.
Is it FOSS or not? It sure doesn't sound like it is.
"We've already accomplished much of what we set out to do"
Then why are you asking for $10k?
There's a lot of text on that page that directly contradicts other text on the page.
To address the money issue further, the $1,000 minimum donation means the donor receives consulting services setting up and administering a node. Anyone with experience with LAMP is able to set up their own node without paying a dime.
And as for funding, I've been working on Appleseed almost full time for quite a while now (started in 2004). I've been working a full time job as well most of the time I've been doing this, so at some point, I'd like to be able to focus on this exclusively, and funding can help make that happen, which means the software will improve faster as a result.
And as for funding, I've been working on Appleseed almost full time for quite a while now (started in 2004). I've been working a full time job as well most of the time I've been doing this, so at some point, I'd like to be able to focus on this exclusively, and funding can help make that happen, which means the software will improve faster as a result.
Maybe off topic but I LOL at doublespeak like "$1,000 minimum donation", and the cognitive dissonance that lies at its foundation. I can just see the whole story behind it: the idealists who preach the 'software should be FREE!' mantra, the myopic hatred against software companies who (gasp) charge money for their software, the realization (after trying to make worth while software themselves) that it actually costs money to, you know, live and pay expenses, and the grasping for straws that is "let's call it a 'minimum donation, then we're not actually charging for it".
Not to pick on these guys, I don't know them and for all I know they're the outlier, it's just such a cliche that it's becoming an indicator of a team that has much to learn about how the software business works.
Not to pick on these guys, I don't know them and for all I know they're the outlier, it's just such a cliche that it's becoming an indicator of a team that has much to learn about how the software business works.
That's a donation, not a fee, and this isn't a business model, it's a perk for making a donation. If you look at similar projects on sites like Indiegogo and Kickstarter, that's how crowd-sourced funding works, with perks provided to people who donate (like t-shirts and servers for the Diaspora funders).
As for "software should be free", the idealists have been qualifying that with "Free as in Speech, Not as in Beer" for as long as I can remember, so we're all fully aware of the material concerns required.
As for "software should be free", the idealists have been qualifying that with "Free as in Speech, Not as in Beer" for as long as I can remember, so we're all fully aware of the material concerns required.
Seriously, come on. A rose is a rose is a rose.
"minimum donation" = fee
"perk for making a donation" = services bought
"crowd-sourced funding" = a bunch of customers pay for products or services.
I mean I'm not being negative here or criticizing you, but let's call things like they are. Why make up fluffy feel-good terms for things for which we already have perfectly viable words?
Referencing the Diaspora guys basically reinforces my point re: the inexperienced team - a bunch of kids straight out of college why manage to hype together 200k and then turn out a complete disaster after a couple of months does not a trustworthy example make.
"minimum donation" = fee
"perk for making a donation" = services bought
"crowd-sourced funding" = a bunch of customers pay for products or services.
I mean I'm not being negative here or criticizing you, but let's call things like they are. Why make up fluffy feel-good terms for things for which we already have perfectly viable words?
Referencing the Diaspora guys basically reinforces my point re: the inexperienced team - a bunch of kids straight out of college why manage to hype together 200k and then turn out a complete disaster after a couple of months does not a trustworthy example make.
It doesn't get much more open source than this:
http://github.com/appleseedproj/appleseed
Source has been available under the GPL v2 for quite a while now.
And we're asking for funding, because there's always more to do. The foundation is set, the features are there, but a project like this is never really done. There's security, threat modeling, scalability and stress testing, and just plain development of future features and bug testing.
http://github.com/appleseedproj/appleseed
Source has been available under the GPL v2 for quite a while now.
And we're asking for funding, because there's always more to do. The foundation is set, the features are there, but a project like this is never really done. There's security, threat modeling, scalability and stress testing, and just plain development of future features and bug testing.
Why don't you join forces with Diaspora?
Or, why would someone decide to donate to you over Diaspora?
Or, why would someone decide to donate to you over Diaspora?
To answer your first question, I did email them back in May offering help but never received a response. I had a chance to catch up with them at the Federated Social Web Conference, and spoke with a lot of similar projects and we're all interested in a common protocol, so in that sense, we're all "joined forces." However, since their project is Ruby on Rails + MongoDB, and Appleseed is LAMP, beyond the protocol, there's not much collaboration on codebases that can happen.
As for why to donate to Appleseed over Diaspora:
1. Appleseed is a much more mature codebase. We've been in development for a while now, and already have around 80 nodes in the wild.
2. Appleseed has a much more experienced developer at the helm. I've been programming web apps professionally since 1997.
3. We have a much clearer roadmap and protocol specification compared to Diaspora, which has yet to hammer out most any specifics in that arena.
4. Appleseed is much easier to install (about 5 min for anyone who's installed LAMP software before).
5. Appleseed is more ambitious. Diaspora aims to be a social networking app, but Appleseed is a social framework, with an extensible MVC model, meant for building new social components.
6. Diaspora already has $200k. :)
As for why to donate to Appleseed over Diaspora:
1. Appleseed is a much more mature codebase. We've been in development for a while now, and already have around 80 nodes in the wild.
2. Appleseed has a much more experienced developer at the helm. I've been programming web apps professionally since 1997.
3. We have a much clearer roadmap and protocol specification compared to Diaspora, which has yet to hammer out most any specifics in that arena.
4. Appleseed is much easier to install (about 5 min for anyone who's installed LAMP software before).
5. Appleseed is more ambitious. Diaspora aims to be a social networking app, but Appleseed is a social framework, with an extensible MVC model, meant for building new social components.
6. Diaspora already has $200k. :)
here's not much collaboration on codebases that can happen
Colaboration on codebases is overrated. Common protocols are where it's at. Stop and think about the web - is a common codebase needed to implement a web server or a web browser? Nope. In both cases there are more than one independent implementations out there. The protocol between the two pieces of software is the common part.
Colaboration on codebases is overrated. Common protocols are where it's at. Stop and think about the web - is a common codebase needed to implement a web server or a web browser? Nope. In both cases there are more than one independent implementations out there. The protocol between the two pieces of software is the common part.
is there any work on a common protocol yet? (mostly looking for a link)
That's a good question, without a simple answer, but here goes:
Right now, we're using something I call QuickSocial:
http://opensource.appleseedproject.org/quicksocial/
This protocol is very much in flux, and being modified regularly. And it may not be the protocol that Appleseed ends up with.
Appleseed is a very flexible system, all the protocol work has been abstracted out into framework "hooks" (plugins), and you can easily replace one set of protocol hooks with another, or even have multiple protocol hooks operating concurrently.
So at some point, there will be support for OAuth, OStatus, Webfinger, etc. And if a unified protocol emerges as a standard, Appleseed will be updated with a new set of protocol hooks to support it.
The advantage of using a homegrown protocol like QuickSocial is that we can focus on userflow and end features without having to cater to another protocol specification, which is fine since we're at such an early point with distributed social networking protocols anyways.
Right now, we're using something I call QuickSocial:
http://opensource.appleseedproject.org/quicksocial/
This protocol is very much in flux, and being modified regularly. And it may not be the protocol that Appleseed ends up with.
Appleseed is a very flexible system, all the protocol work has been abstracted out into framework "hooks" (plugins), and you can easily replace one set of protocol hooks with another, or even have multiple protocol hooks operating concurrently.
So at some point, there will be support for OAuth, OStatus, Webfinger, etc. And if a unified protocol emerges as a standard, Appleseed will be updated with a new set of protocol hooks to support it.
The advantage of using a homegrown protocol like QuickSocial is that we can focus on userflow and end features without having to cater to another protocol specification, which is fine since we're at such an early point with distributed social networking protocols anyways.
Is there a site somewhere about this project (not just github)? Screenshots? Features? Information? Can't seem to find a link anywhere?
Edit: here we go: http://opensource.appleseedproject.org/
Edit: here we go: http://opensource.appleseedproject.org/
Here's all the resources associated with Appleseed. They're on the indiegogo page, but they're a little hard to find.
- General Links
Main: http://opensource.appleseedproject.org/
Fundraising: http://www.indiegogo.com/Open-Source-Social-Networking
Drumbeat: http://www.drumbeat.org/project/appleseed-social-networking
Beta Test: http://appleseedproject.org
Facebook: http://www.facebook.com/group.php?gid=366560616455
Twitter: http://twitter.com/appleseedproj
Identi.ca: http://identi.ca/appleseedproj
Youtube: http://www.youtube.com/user/appleseedproj
- Development Links
Source Code: http://github.com/appleseedproj/appleseed
Packages: http://opensource.appleseedproject.org/download/
Bug Tracking: http://appleseedproj.lighthouseapp.com
Discussion Mailing List: http://groups.google.com/group/open-social-networking
- General Links
Main: http://opensource.appleseedproject.org/
Fundraising: http://www.indiegogo.com/Open-Source-Social-Networking
Drumbeat: http://www.drumbeat.org/project/appleseed-social-networking
Beta Test: http://appleseedproject.org
Facebook: http://www.facebook.com/group.php?gid=366560616455
Twitter: http://twitter.com/appleseedproj
Identi.ca: http://identi.ca/appleseedproj
Youtube: http://www.youtube.com/user/appleseedproj
- Development Links
Source Code: http://github.com/appleseedproj/appleseed
Packages: http://opensource.appleseedproject.org/download/
Bug Tracking: http://appleseedproj.lighthouseapp.com
Discussion Mailing List: http://groups.google.com/group/open-social-networking
Just for kicks,
Let me ask how a project like this could provide possibly any more privacy than a situation of a group of people who each having a mailing list with which they email messages to their friends?
Seriously.
Maybe I'm not thinking clearly tonight but I can't see any plausible way to provide "more security" than the security of deciding what message to send to what friend. Am I missing something.
-- I mean, you just aren't going to keep your friends from forwarding your messages. They'll video-type to screen if they need to. You might decide not to forward them more messages but that's different.
Let me ask how a project like this could provide possibly any more privacy than a situation of a group of people who each having a mailing list with which they email messages to their friends?
Seriously.
Maybe I'm not thinking clearly tonight but I can't see any plausible way to provide "more security" than the security of deciding what message to send to what friend. Am I missing something.
-- I mean, you just aren't going to keep your friends from forwarding your messages. They'll video-type to screen if they need to. You might decide not to forward them more messages but that's different.
I mean, you just aren't going to keep your friends from forwarding your messages.
There's a difference between privacy and trust. Software can't predict when your best friend is going to turn against you for emotional or social reasons.
If you share something with ten friends, and one of them betrays your trust, technology can't predict or prevent that.
However, if you share something with ten friends, and they all act properly and trustworthy, you have a reasonable expectation that your data won't be available to anybody but those ten friends.
There's a difference between privacy and trust. Software can't predict when your best friend is going to turn against you for emotional or social reasons.
If you share something with ten friends, and one of them betrays your trust, technology can't predict or prevent that.
However, if you share something with ten friends, and they all act properly and trustworthy, you have a reasonable expectation that your data won't be available to anybody but those ten friends.
Agree with this but it doesn't answer my original question.
Why bother with encryption when each person having an email list would work as well as anything for distributing information? Why? It's like UPS buying armored cars to deliver your packages with but still plunking the package down outside your house when you're not home.
I have a reasonable expectation of privacy sending email through a webmail account. If I was sending the corporate crown-jewels or something, I'd encrypt my message but email these days is appropriately secure.
I'm asking these questions with the best intentions too. I like the idea of a Facebook alternative - I'm working on my project along those lines in fact. The thing is that to offer an alternative, you've got to be clear what services Facebook offers and how one could offer them better. It seems like a lot of upset over Facebook confuses Facebook's abuse of user data with the inherent insecurity that comes from sharing information with any group of people. We'll have to educate ourselves and our users about the difference if we want to have this Facebook alternative thing get off the ground.
As far as I can tell, almost everything Facebook provides is something you can do with the "regular web". Facebook simply puts everything in a nice package (and that nice package matters a lot as we've seen). If you had a script which aggregated your friend's blogs, tweets and emails, you would have something like Facebook. The only service that would be required is friend-discovery and perhaps a "like" messaging system. The rest could just involve wrapping/packaging existing stuff.
The thing about Facebook and walled-gardens in general is that they really entice people who otherwise wouldn't participate in "cyber life" to come onto the web. But Facebook users hopefully will also be learning that their walled-garden doesn't offer the protection it claims and hopefully they'll realize that nothing can simultaneously offer free-sharing and perfect privacy in the modern era - your friends' friends just aren't necessarily going to be your friends etc.
So we "Facebook alternativists" have to offer something that gives the good stuff that a social network can realistically provide for people who are over the illusion that they can live in a one-identity, total-trust world.
Why bother with encryption when each person having an email list would work as well as anything for distributing information? Why? It's like UPS buying armored cars to deliver your packages with but still plunking the package down outside your house when you're not home.
I have a reasonable expectation of privacy sending email through a webmail account. If I was sending the corporate crown-jewels or something, I'd encrypt my message but email these days is appropriately secure.
I'm asking these questions with the best intentions too. I like the idea of a Facebook alternative - I'm working on my project along those lines in fact. The thing is that to offer an alternative, you've got to be clear what services Facebook offers and how one could offer them better. It seems like a lot of upset over Facebook confuses Facebook's abuse of user data with the inherent insecurity that comes from sharing information with any group of people. We'll have to educate ourselves and our users about the difference if we want to have this Facebook alternative thing get off the ground.
As far as I can tell, almost everything Facebook provides is something you can do with the "regular web". Facebook simply puts everything in a nice package (and that nice package matters a lot as we've seen). If you had a script which aggregated your friend's blogs, tweets and emails, you would have something like Facebook. The only service that would be required is friend-discovery and perhaps a "like" messaging system. The rest could just involve wrapping/packaging existing stuff.
The thing about Facebook and walled-gardens in general is that they really entice people who otherwise wouldn't participate in "cyber life" to come onto the web. But Facebook users hopefully will also be learning that their walled-garden doesn't offer the protection it claims and hopefully they'll realize that nothing can simultaneously offer free-sharing and perfect privacy in the modern era - your friends' friends just aren't necessarily going to be your friends etc.
So we "Facebook alternativists" have to offer something that gives the good stuff that a social network can realistically provide for people who are over the illusion that they can live in a one-identity, total-trust world.
Do we really need one more Social Network?
Yes, because a distributed protocol means that it will effectively be the last social network.
that's pretty delusional. Users don't care about protocols, they care about interface usability. And the ONLY thing that makes a social network valuable is its users. There will always be more room for more niche social networks with well defined UX constraints if developers continue the facebook trend of bloat sites with ambiguous constraints.
It's really quite simple. Once an open protocol is established and popularized, then social networks are just software that connect into the distributed network.
Think of it in terms of SMTP and e-mail. Mail providers come and go, but nobody has to move email providers because all their friends changed emails.
Think of it in terms of SMTP and e-mail. Mail providers come and go, but nobody has to move email providers because all their friends changed emails.
> Once an open protocol is established and popularized
"popularized" is the most important and hardest part, you can't risk using it in an assumption. The problem domain you are working in is the exemplar of the chicken-and-egg user growth difficulties.
Also if it really was just a protocol: the only thing being developed would be QuickSocial, it would not be called a social network because a protocol is not the place creating the social experience, it would be marketed to developers and bloggers as an improved and easy to add replacement for OpenID, 50% of the work would be on rigorously defining QuickSocial specification, the other 50% on developing plugins for all platforms and languages.
"popularized" is the most important and hardest part, you can't risk using it in an assumption. The problem domain you are working in is the exemplar of the chicken-and-egg user growth difficulties.
Also if it really was just a protocol: the only thing being developed would be QuickSocial, it would not be called a social network because a protocol is not the place creating the social experience, it would be marketed to developers and bloggers as an improved and easy to add replacement for OpenID, 50% of the work would be on rigorously defining QuickSocial specification, the other 50% on developing plugins for all platforms and languages.
it would be marketed to developers and bloggers as an improved and easy to add replacement for OpenID, 50% of the work would be on rigorously defining QuickSocial specification, the other 50% on developing plugins for all platforms and languages.
That's part of the plan. QuickSocial is being developed as an abstracted PHP class library that's quite easy to implement.
That's part of the plan. QuickSocial is being developed as an abstracted PHP class library that's quite easy to implement.
Maybe I'm being patronize and you know all this all but I'll just note that a protocol is about one level of abstraction above a class library.
I'm biased because I'm working with c++ but I'd suggest the protocol be developed like most protocols - in a language neutral fashion. This involves writing it in a fashion akin to an abstract language. Normally, such a protocol spec simply say what byte means what and where each byte goes. Then the protocol can be implemented in any language.
For example: http://en.wikipedia.org/wiki/Http
Also, I'd suggest only creating a new protocol for things that really can't be done existing protocols (such as Internet mail). You always layer your application on top of an existing protocol if it serves your purposes.
I'm biased because I'm working with c++ but I'd suggest the protocol be developed like most protocols - in a language neutral fashion. This involves writing it in a fashion akin to an abstract language. Normally, such a protocol spec simply say what byte means what and where each byte goes. Then the protocol can be implemented in any language.
For example: http://en.wikipedia.org/wiki/Http
Also, I'd suggest only creating a new protocol for things that really can't be done existing protocols (such as Internet mail). You always layer your application on top of an existing protocol if it serves your purposes.
Nothing about the protocol is PHP-specific, but the initial implementation is written in PHP.
I don't agree with this. There are many other problems to be solved. World doesn't need yet another Social Network.
Perhaps my PHP-design skills are outdated, but is it normal to have a 1500 line index.php containing a mixture of configuation code, PHP functions and HTML?
Also, don't you use any template system?
... I cloned the github project, only to find myself confused :)
Also, don't you use any template system?
... I cloned the github project, only to find myself confused :)
The index.php file is the install file.
The actual system is re-routed using mod_rewrite. After installation, it never uses index.php again.
Also, don't you use any template system?
No, actually, I use a different approach. Using simple_html_dom, I target the dom within the controller. The views are layout skeletons that are then populated with data. Check out the example component's comments for more info.
The actual system is re-routed using mod_rewrite. After installation, it never uses index.php again.
Also, don't you use any template system?
No, actually, I use a different approach. Using simple_html_dom, I target the dom within the controller. The views are layout skeletons that are then populated with data. Check out the example component's comments for more info.
Don't "they" know that the Appleseed family is very litigious?
I was going to rename it to Bananaseed, but I think someone with that name killed a bunch of nurses in Portland. /30rock
it's just too bad you never got back to me last year mike (via red emmas) :(
not sure how else to contact you. I'll delete this post later
Not sure who this is, but my email is [email protected] if you need to get in touch.
cool thanks. and now i realize it's too late to delete. Sorry folks :(
The reason I ask is that I don't see how that's possible. Here's an example. Let's say that I'm on MySeed and you're on Applebook. We friend each other and, lovely, now my posts get aggregated to your feed and your posts get aggregated to my feed. Life is good. Then Applebook turns evil and decides that it's going to make all posts open (they have the source code and the data). Well, now I no longer have privacy. Heck, let's say I post something and it gets aggregated to your feed. Then I delete it. Does Applebook then delete it? There's no real way to force a deletion. And I realize that anyone who saw it could have just done a copy/paste and saved the post, but it's different when it's happening automatically.
The only way I could see this working is through public key encryption. When we friend each other, I get your public key and you get mine. You can then make your postings available encrypted with my public key and when I get them I can decrypt them with my private key. BUT I must not store my private key with MySeed since then MySeed could decrypt your posts and you no longer have privacy. Right now, browsers don't have support for encryption like this where part of a web page will be encrypted not by the server, but in the data storage.
But even that has problems. It means that if you're friends with 500 people, 500 copies of any status message you post have to be encrypted and stored separately for each of those 500 people. Considering the scaling issues that Facebook has to contend with, I think adding a step where everything people post gets encrypted and stored N times (N being the number of friends you have) would be troublesome.
Heck, what about pictures? It's one thing to encrypt and store a short 140byte status 500 times. It's another to do that for an 80k photo.
tl;dr: If we're friends and you're on another service, what stops your service from aggregating my postings and then making them public to the world against my wishes?