I think it's fascinating to see distributed social networks from a tech perspective. From what I've seen so far they exacerbate the problems that Facebook has been seeing so much backlash against.
1. The whole Cambridge Analytica issue was caused by APIs that are too open. For distributed systems there are more ways to exploit the APIs and gather data on users.
2. There is a clear issue with Facebook's accountability in these areas. Distributed systems are typically open source, they run on multiple servers by different owners, this leads to zero accountability.
3. GDPR compliance about deleting data is almost impossible in a distributed system.
4. Some of the problems with Facebook are more about usability and clarifying how things work to users. For instance the scandal with people giving away access to their private messages. Open source software and distributed software tends to be much harder to use.
5. Any future concern/issue will be much harder to resolve if there are thousands of different instance running decentralized social networks.
6. Using AI to detect abusive content or spot fake news is much harder if you only have a subset of the data. So it becomes harder to address those concerns in a distributed setting.
So while I think this stuff is awesome from a tech perspective, in many ways it just makes these problems harder to solve.
I think your post hints at a general schizophrenia in the latest, culture-war-fueled push against Facebook. On the one hand, the public debate is still significantly dominated by the old guard of anti-Facebook activists, whose objectives can be summarised as "Facebook's power over its users must be reduced". On the other, the renewed interest in doing /something/ about Facebook in the wake of Cambridge Analytica and fake news (and, before that, cyberbullying, stalking, harassment...) essentially amounts to "Facebook's power over its users must be exercised to quell evil". More often than not, the two are actually diametrically opposed (as when quelling evil turns out to require an increase in power). A hypothetical actually usable decentralised social network would advance the former cause, and, as you pointed out, set back the latter.
I think grandparent's point was that the first cause you mention - reducing FB's power over users - does nothing for the users if this power instead goes to other 3rd parties, and perhaps even grows.
GP points out that in a distributed social network, 3rd parties can still mine your data, you still have trouble permanently erasing information, and in fact these problems grow instead of shrink. From a user's POV, what matters is the total amount of 3rd parties over them and the leverage they have against these 3rd parties as a whole. GP's point is that shrinking FB's power by going to a distributed social network might actually increase the total power 3rd parties have over users.
> The whole Cambridge Analytica issue was caused by APIs that are too open. For distributed systems there are more ways to exploit the APIs and gather data on users.
Huh? Scuttlebutt is fully encrypted.. doesn't that make the API vastly more locked down than Facebook/etc?
> There is a clear issue with Facebook's accountability in these areas. Distributed systems are typically open source, they run on multiple servers by different owners, this leads to zero accountability.
This is no worse than Facebook though. With Facebook, your friend could steal all of the data you let them see. With Scuttlebutt, your friend could steal all of the data you let them see.
At least with this I control who sees my data, no? Sure, I can't have accountability with a friend, but at least no company/etc has access to my data.
> GDPR compliance about deleting data is almost impossible in a distributed system.
Doesn't GDPR apply to companies? If my mom sends me a physical card, do I have to adhere to GDPR laws with her address/name? How is that any different than Scuttlebutt?
> Scuttlebutt is fully encrypted.. doesn't that make the API vastly more locked down than Facebook/etc?
Encryption has nothing to do with it. The whole issue with CA was that they (just as many apps before them) were using Facebook social graph data that was available for them to access via the API. Encryption on any layer has nothing to do with it - if you have access to the API, you get the data. In distributed system, if you are a node in the system, you have to have access to social graph data - otherwise the whole concept of social network does not work. You can't "see what your friends are doing" if there's no information about who your "friends" are. And if the nodes on the network have information about who your friends are - or can get that information - then they have the same access as CA (and many other apps before them) had. Facebook can at least (if they wanted to) cut off the external API and not tell the social graph structure to anybody outside Facebook. I don't see how this is possible in a distributed network.
Scuttlebutt is not at all "fully encrypted", it's fairly trivial to spider and download just about everything. The hardest part is the first foothold (which can be found posted various places, including the official docs on ssb), from there, downloading the entire "social web" it has can be done with the "main client" by basically changing a single config value.
It's worse than facebook because there's no one to have responsibility to be accountable. This ties in with your question about GDPR. While I'm not a lawyer, as far as I know it doesn't matter if you're a person or a company, if you're collecting data, it's something you can be liable for. So in a distributed system, all parties who maintain the data sources would be liable. I actually wonder how this works logistically in terms of storing account info on something like Ethereum.
> Scuttlebutt is fully encrypted.. doesn't that make the API vastly more locked down than Facebook/etc?
No, not at all! TOR is fully encrypted, but there are somewhat regular vulnerability reports about various parts of the stack. Including criticial vulnerabilities that can and have been exploited by nation states, for example.
> This is no worse than Facebook though
This is not at all clear to me. The attack surface for Scuttlebutt is much larger, and I trust Facebook's security team to audit and patch much more than I trust any random friend.
> This is no worse than Facebook though. With Facebook, your friend could steal all of the data you let them see. With Scuttlebutt, your friend could steal all of the data you let them see.
Your friend can, but Facebook can scrutinize third-party apps. In a decentralized world, there's no one who has access to holistically examine automated access and detect shady activity. In a decentralized world, everything is essentially a third-party app.
I see that you don't understand the problems raised.
About accountability: if YOU are compromised, your friends' data are compromised, and vice versa. Are you saying that the median security skill of your friends are higher than Facebook? Because any of them can leak your data unintentionally.
About encryption: it's freaking useless in this case. Remember, some people fall for Nigeria prince scam. And what happen when their keys are compromised? See above.
That's the crux of the argument: you can't guarantee that your precious friends and family can safeguard their keys (in fact, I doubt my personal security practice is remotely as good as FB or Google or Amazon or MS or Apple). In that case, by the virtual of distribution, your data is copied everywhere, waiting for any key to compromise.
1. Follow you from site to site, scooping up all the data they can on you.
2. Allowed all of that data to be accessible not just by you opening up to a bad actor app, but by any of your friends opening up to a bad actor app.
Calling it "overly open APIs" is misleading at best. The point of an API is that it is a public interface. If Scuttlebut has proper permissions controls then they wont have these problems... and because they're open source those problems can be scrutinized rather than remaining opaque.
How can Scuttlebutt prevent (2) from happening? If you share data with your friends, how can you know that they haven't installed an app that will slurp up that data wholesale?
The only solution would to be to enforce reasonable app usage in the client, and then require all your friends to use that client. That seems to defeat the purpose of a decentralised protocol.
You're missing one very large differentiator: user control.
With Scuttlebutt, largely, the client controls every one of your points. Different clients (with different settings/controls) can interact with a network upon which other users are using completely separate clients, each with separate settings controlling how user data is contributed to the network. Consent is not an issue.
With Facebook, as a user, you need to agree to Facebook's strict terms to be a part of their closed network, and—largely—cannot do so with your own client with its own data-contributing settings. The only close equivalent is using something like uBlock with your own browser, but the control you have their is very limited.
I say consent is not an issue but I'll devil's advocate myself and describe a Scuttlebutt setup where it would be. Say a company sets up a normal centralised service, which you visit in your browser, sign up for a central account, and it's backed by Scuttlebutt behind the scenes. Users of that centralised service can connect to a larger Scuttlebutt network upon which other users may be using their own dedicated clients to access. Consent is an issue for that central service (which acts as a defacto client on your behalf), but not for the network at large.
In my case, I don't care about the "privacy protection" of a given social network: I assume that everything I post is public (except private messages), so I filter what I upload based on that assumption.
Things I do care about:
-No censorship
-Chronological feed
-Open source & non-abusive client. (i.e. no tracking what users see or read)
-Good usability
I don't care about abusive content or fake news. If I see fake news, I just stop following whoever posted it.
We fail to consider policy when thinking about centralized/federated services. Centralized services provide strong, regular policy adherence across the network, whereas federated services provide weak, irregular policy adherence across the network. Centralized services can effectively silence a bad actor. They may also silence a good actor, but generally only under external pressure from government. Federated services have little or not ability to silence bad actors across the network, though individual instances may effectively silence "bad" actors. However in this capacity "bad" is not well understood and can simply mean the instance administrator does not like the person the silence. Individual instances may also give voice to bad actors.
The GDPR argument is a bit moot because Scuttlebutt is no different than sharing pictures in gossip style (a.k.a. memes). If one of your childhood pictures happens to become the new meme, there's little hope that GDPR enforcement would suffice to de facto delete it from the internet: from Reddit, from Imgur, from independent websites, from Torrent, etc. The same is with Scuttlebutt, but data is primarily shared between friends without contracts, not from people to a particular company. GDPR applies to institutions.
The other points are just stating "much harder", which seems to just bring skepticism and little actionable suggestions.
I have similar concerns. If I had a magic wand, I'd solve this by splitting Facebook into an infrastructure-and-core-data non-profit and one or more for-profit companies that are building tools or interfaces on that platform.
I think there is a natural monopoly for some aspects of this, which is why Facebook is so hard to quit. But I don't think the whole thing need be in private, for-profit hands. Mozilla shows that a nonprofit can be a good steward of important web assets, with much stronger user advocacy than for-profit companies normally do.
Doing something like that for identity and interconnect between messaging and micropublishing providers seems much more robust than pure decentralization to me, which I expect would have the same failure mode as OpenSocial [1], where forces pushing toward natural monopoly are basically unchecked.
I think decentralisation is the wrong way to look at it. The protocol itself becomes the point of centralisation with many providers implementing in federation. Nothing to stop any of them being commercial (they may have all kinds of ease of use and features on top) or not. Since you lose the network effect of bigger player owning 'footfall' (e.g. ebay), there should be less natural tendency for monopoly and greater incentive towards user needs. For example, a more privacy conscious provider may choose to only share limited data with the wider federation. Others may be all about the exposure and getting more followers. (I'd expect federation to allow users a way to export their full profile+history and migrate to another provider taking their data away with them.)
It's a philosophical issue, negative liberty vs. positive liberty.
Positive liberty is the distribution of responsibility to the collective (and managing/controlling the collective through central bureaucracy), negative liberty is distributing the responsibility to the individual, self organization, or stateful components in dev lingo.
Your error is that you're set on only one perspective, positive liberty, like many people in europe. GDPR is like that, instead of giving people the tools to protect themselves, and not leak data in first place, and educate them about voting with their wallets, they just take it from the individual and apply it to the collective.
That's the mindset of centralization. It's clear that decentralization efforts fail if you insist on distributing the responsibility collectively.
Personally, I hope (and I think I'm not alone here) that on a network like scuttlebutt, there will be much less "noise" than on facebook.
My timeline on facebook (whenever I check it, like weekly) is a mishmash of...
* ads (if using a browser that doesn't get rid of them)
* "you missed someone's birthday who you didn't even remember you were "friends" with
* look at this really popular post in your social vicinity, ENGAGE!!!
* cat/dog/food pictures
* politics of the same kind I had to ignore as a teenager, back then by mail. Sign $petition here!
* the occasional thing I give a flying fk about
This is not accidental. It is what facebook is built to do: keep you on their page, engaged.
Scuttlebutt and such don't have that incentive. Liking "Pizza" or "Justing Bieber" doesn't exist. You can like a specific post, but that's not the same as putting your entire preferences on there. The possibility to digitally model your entire family and social graph and all your preferences in the open doesn't exist, simply because... why would someone implement that? And why would they then gear the UI to reward you for doing that?
And it's not as inherently in danger of becoming an across-sites profile kept by a single entity.
I know you must be high school or college aged, because you didn't mention baby photos. Watch out. That's going to take over your feed in a couple years.
> 1. ... For distributed systems there are more ways to exploit the APIs and gather data on users.
However there is no global state, users only push-pull feeds of friends and friends of friends. (In part for privacy and in part for performance, you don't need to carry all the data for a social network to be useful)
> 3. GDPR compliance about deleting data is almost impossible in a distributed system.
However that doesn't apply to individuals that aren't providing a public service.
> 4. ... Open source software and distributed software tends to be much harder to use.
> 5. Any future concern/issue will be much harder to resolve if there are thousands of different instance running decentralized social networks.
There are no instances, only peers. (Pubs are sort of easy to connect to peers and there is work being done on peer discovery to outdate most pubs; they could still be used to connect communits around topics, hobbies, etc as a way to reduce the distance between peers)
> 6. Using AI to detect abusive content or spot fake news is much harder if you only have a subset of the data.
There is no retweeting/sharing, though there is work being done on Out of Order Messaging to propagate a single message along the follow graph and there is work being done on flagging/tagging feeds/ids and posts. (Along with some semantics around how to interpret the flags/tags to improve UX and user control)
> There are no instances, only peers. (Pubs are sort of easy to connect to peers and there is work being done on peer discovery to outdate most pubs; they could still be used to connect communits around topics, hobbies, etc as a way to reduce the distance between peers)
Why do you draw this distinction between "instances" and "peers"? A conventional understanding of the word "instance" would suggest it means "a running instance of the software system in question", which would suggest the word has no meaning distinct from what "peer" would mean in this context. Am I missing a critical and non-obvious distinction?
> There is no retweeting/sharing
My experience is that users really like these features.
> Pubs are sort of easy to connect to peers and there is work being done on peer discovery to outdate most pubs;
this is cool! could you explain more?
i thought Pubs were needed to connect with peers on internal networks, to alleviate NAT traversal issues.
what i would like to know more about regarding Pubs - but could not find any info on some time ago - is how much it will cost, more or less, to host your own Pub in terms of data transfer/storage, CPU, etc. and whether rate limits can be set to manage this.
nice to see your docs.. i have them bookmarked for later :)
Well, it's not a Facebook replacement for the masses. It's more of the alternative in the way that Linux used to be an alternative to Windows long time ago. Linux was a nightmare for the majority, but for tech-inclined people (with a lot of spare time one might add) it offered a lot more safety and power, at the price that you had to learn how to set it up and use properly first. Same applies here. If you share data that shouldn't be shared it will not protect you, but if you know what you're doing it gives you a lot more control and safety.
Your concern about APIs in distributed systems seems to neglect the fact that cryptography can be used to ensure that only the right people have access to the data.
Although I do agree on the fake news point you make.
It’s hilarious that people think Facebook could be held accountable. Senators didn’t say we need rules for privacy protection or that any specific response should be made by them to CA leaks, just a vague “do suff better or we might regulate you”
These guys really have free reign and just get a slap on the wrist WHEN ELECTIONS ARE MEDDLED WITH.
We should leave their platforms in droves to deprive them of power cause it seems like even the US Congress won’t stand up to them.
Alternative explanation: if they actually go after Facebook all the previous shady shit US politicians have done would also come into question. So they'll stick to emotive appeals like "when elections are meddled with" instead of specific, measurable outcomes.
Recall that the Obama campaign got the explicit go ahead from FB to violate their privacy policy, and built up equally large databases. Heck, recall Obama explicitly endorsing Macron. Does that count as large scale meddling?
What's hilarious is that the same people worried about internet driven misinformation are now the ones jumping into action because the media told them to #deletefacebook.
"1. The whole Cambridge Analytica issue was caused by APIs that are too open. For distributed systems there are more ways to exploit the APIs and gather data on users."
No, the issue was that other people had access to data they shouldn't have. there's no problem with the API being open if only the right person has access to the right data, ie, if access management is done right
You are mixing up openness of the code and protocol with access to data. Access to data should be managed by security features, and security through obscurity isn't the proper method anyway.
this entire complaint centers on the over-paternalistic notion that it is the service operators responsibility, rather than the users, to solve these problems, and that this is the desired state of affairs.
1) ... on the users that have chosen to enable this
2) ... for the users that use other peoples servers or servers from disreputable people, or share to those who do the same.
3) ... and? this presumes GDPR is a good thing
4) ... it's impossible to view a list of viewed messages, perform bulk operations, flag, sort, group etc. facebook to the same level that can be done in other 'archaic' technologies such as email. presuming commercial ui's are designed for user friendlyness rather than increasing user engagement, etc. is a red herring. also, strawman.
5) much like HTML, TCP/IP, SMTP, HTTP and everything else the internet runs on?
6) which is why spam filters don't work? and users don't have brains to do this themselves?
The principle is that the network can become federated, which makes it possible to switch providers while remaining on the same network. This allows there to be competition between providers. Presumably, providers would compete based on their ability to protect your data. Facebook, on the other hand, competes almost solely based on the size of their network, which eclipses every other factor like accountability.
You are assuming the network holds personalized data.
While this is true for facebook (because this is their business model) it is not necessarily true for a non commercial social network.
Not saying that scuttlebutt is useless, but within the parent's perspective, almost everything applies as well on HTTP and HTTPS. But no one seems to care? I mean, google caches your website on their machines and so on, be it personal or not.
I guess once things become ubiquitous enough, they start to become invisible.
Whois service, I heard recently, was being scrutinized over personal data in the context of GDPR, so it's not ALL invisible.
> 6. Using AI to detect abusive content or spot fake news is much harder if you only have a subset of the data. So it becomes harder to address those concerns in a distributed setting.
Maybe people will have to start paying the market what this data is worth, as opposed to burying it in EULAs and using venture and angel funding to create a next generation data oligarchy more difficult to overcome than any financial oppression?
I think the idea is no ads -> nothing to target -> no need/value for personal data. Sure, maybe Cambridge Analytica can scrape Scuttlebutt or Mastodon but then what can they do with that data?
Aside from the likely ability to connect it to other sources of data so they can show better ads on those platforms, there's regular market analysis - it's worth knowing that teenagers are increasingly interested in X even if you can't tie that back to individual teenagers.
Okay Hackernews, I get it. Scuttlebutt isn't fully ready for everything yet. I wrote that article hoping that it would sparkle interest to both use it, plus make it happen.
This is not your usual startup launch, it's a community project by multiple open source hackers. If something is missing, you can make it happen. And there are so many ongoing developments right now (see list below), that it really doesn't make sense, at this point, to point out the current problems with the protocol. It's evolving fast, and can evolve even faster if you choose to make it your own and do something about it.
Here are a couple of things being developed:
- Mobile app for Android
- Better cryptographically-verified user invites
- P2P replication over WebRTC
- P2P replication over DHT (Kademlia)
- Better scalability (Epidemic broadcast trees)
- GitHub alternative
- "Out-of-order" replication (get messages from distant friends of your friends)
- Private groups
- Moderation tools (every person as a moderator)
- Socio-technical discussion around data accountability
- New RPC stack, rewrite
- Rust client
- Go implementation
- C implementation
- Groundwork for iOS support
- Multi-devices accounts
- Scuttlebutt on Firefox as an extension
- Overall improving onboarding and docs
- Replication over Bluetooth and Wi-Fi P2P
- Web viewer
- Scuttlebutt cloud (easy way of setting up servers)
I'm super impressed with all you've done. I've been white-boarding similar ideas for a couple of years from the other side concerning protocol security, secure messaging, user identity management and related which utilizes Curve25519 and related crypto.
I think these ideas will change the world for the better.
2018 will be the year of "alternative to facebook" apps that are in no way an alternative to facebook.
To be an alternative to facebook, it should at least do 50% of what facebook does, and it should be accessible to all.
Anything that takes more than 3 steps to get it running it's going to keep people out. And if you keep people out, you don't have a social network, at least not anything like facebook where your grandma and people you went to school with but never met (or pretend you never met) are.
Plus you need marketing, a business plan, and so much more than just code that puts people together on the same page.
I hope for a social network where the data belongs to the user, but unless you get the complication out of it... it will be just something cool but not worth the time.
It's a common mistake to attribute the success of Facebook to its features (it boils down to microblogging + threaded discussions). The usefulness (i.e. product from a marketing perspective) of Facebook isn't its features, it's the people who joined it. Look at Google+, it's not that bad in terms of features. But it lacks people, therefore it's not a competing product. A competitor would be not someone who does 50% of what FB does. It would be someone who has 50% of what Facebook has.
Ahh, see, this is the second problem with Facebook alternatives- everyone misunderstands what other people use it for. For a younger demographic Facebook is not about microblogging at all. It's a (a) chat, (b) photo sharing, and (c) event/group organizer website. Everyone I know has a Facebook and uses it daily- can't remember the last time any of my closest friends posted a status.
I am very interested in the UI/UX opportunities for training the decentralized generation how to interface with decentralized systems and manage their identities, especially across devices and contexts. This has been my biggest criticism of pretty much all of the attempts at a decentralized version of an existing mainstream web service that I have seen.
I love the decentralization community but it often feels very much like an engineer's realm, probably because it's mostly interesting from an engineering perspective. Maybe it's just who I follow, but I don't see a lot of activity in this area from user experience designers. Some collaboration could really help build a decentralized service that stands a chance of truly competing in the global space. Thus far I think it's highly unlikely the average mainstream user will convert.
You can build 'a facebook' in Drupal which is more or less functionally equivalent and people have been doing that for years. But you still have the real work - building the network of users, which is where the value lies and not the software features (which are mundane in the case of fb).
What's far more compelling but challenging is open source federated social networking, which is a facebook on rocket fuel and overcomes the network effect as each provider implementing adds to a shared network. Even if it takes decades, this is going to be the inevitable model and fb will end up either joining in as a provider or do a myspace.
You're absolutely right! A protocol doesn't need a business plan.
Of course, a protocol by itself isn't very useful. You need services using it and systems implementing and supporting it, which do cost money and require some kind of resourcing model...
Cheap cop-out. "some webmail provider" is what runs 99.999% of email. The people who run their own email, or run off hobby email servers, are insignificant.
You can't turn a blind eye to where the majority of users are going to be if you're implementing anything that actually needs traction in order to be successful.
I really love the concept of this. I travel a ton and am without internet for days/ weeks at a time. Scuttlebutt allows me to keep up to date with friends and communities while offline and when I do eventually get online, just grab the newest updates and download them locally.
This is such a cool thing in my eyes for parts of the world with little / no internet access. The creator of the project (AFAIK) sails around the world and, again, has little internet access. this allows him to keep people updated when he eventually does find internet.
It isn't an alternative to Facebook unless my grandma can use it, and she couldn't set this up for herself.
The idea that centralized storage is the problem masks the actual concern. There is nothing inherently wrong with centrally stored data. There is a problem is when it is locked down by a 3rd party, and/or you don't control how it is used.
> There is nothing inherently wrong with centrally stored data.
I'd argue that a 3rd party having the personal details and communication logs of 2 billion people is a massive problem. Privacy, governmental data requests, accidental information leakages, profiling, job applicant scrutiny, fake news, spam, data misuse by employees etc. Or even worse, in times of war.
Actually with a few tweaks, this technology would be much simpler to use than Facebook, for a person like your grandma, simply because it removes that annoying registration process. You just open the installed app, and that's it.
It's odd that we got used to the idea that "(1) registration, (2) strong password creation, (3) username selection (in case of conflicts), (4) email verification link, (5) login" is somehow a good user experience.
I have a question, how would my Grandma signal her identity to SSB from multiple devices? Say she has an iPhone and an iPad and she wants to use the iPad at home and the iPhone when she's out. I imagine it's not as simple as installing the app on both devices in this case? I'm curious how this is approached.
Cycle.js and xstream are amazing, as an aside. Thank you.
This is a variant of survivership bias and says effectively nothing.
Just because things have gotten more complicated and people have used them doesn't mean that people will start to use any complicated thing.
For example:
Google+ / Google Wave isn't an alternative to email if my grandma can't use it.
GPG isn't an alternative to talking in-person communication if my grandma can't use it.
... etc
Yes, you have valid examples where things that are relatively complex did become popular, but there are many many more examples of things that were more complicated and failed.
Just because scuttlebutt is complicated is not a reason it will succeed, but is indeed a valid reason it might fail.
Okay, but FB wasn't something your grandma used when it began.
Arguably it isn't FB if regular college kids can't use it. If they can subsequently onboard less tech savvy people, so be it, but that could be a future goal.
Why do we even want to be in a creepy digital relationship with our grandma? I used to think like you, then one day I realized that the real life is outside, I began calling my aunties, visiting them, and also created a Whatsapp group so the big family can have fun & share updates.
You do realize Whatsapp is owned by FB, right? so it's a "creepy digital relationship with our grandma" in exactly the same way messaging Grandma on FB is. The key issue here is not whether we use digital comms channels (or telephones, or carrier pidgeons), but whether those comms channels lead us towards getting together in person with our families and friends, or whether they lead us towards spending more ticking clicking around the comms channels. Check out Joe Edelman's videos on Vimeo about human-centred design for a more detailed discussion of this and related issues.
I live at the base of a mountain, and hike every day after work. I spent all last summer exploring every park in my state, and was on the news as an expert guide for some of the outdoor activities in my area. So you are presuming a lot by your response. My grandma, on the other hand, is in her 90s and not very mobile, and can keep up with family via their digital presences. Like you said... "the big family can have fun & share updates".
I downloaded Patchwork after someone talked about Scuttlebutt on HN, but when I tried to join any pub servers on their Github repo, none of them worked/connected. 30 minutes later, I uninstalled the thing.
The idea was interesting, the UI was pleasant, and I could see this working at some tech conference where people connect with each-other and there's a common pub server so people can keep in touch afterward, but I don't see uncle Joe or grandma using this thing over FB.
I joined a pub but 90% of the messages in my feed were other people joining the pub and subscribing to topics. 9% were people introducing themselves as new to Scuttlebutt. 0.9% were either talking about Scuttlebutt or unreachable, and 0.1% were actual content.
Sounds like you joined during a wave of new people and were only getting posts from your shared pubs. Did you contribute any content yourself and build out a network and thus increase your feed? I've been on for a year now and there is a ridiculous amount of information to read.
I was held back from using Scuttlebutt because of how convoluted it seems. I browsed the website for 30 minutes and I couldn't find a concise, written explanation of how the protocol works. And now this? If I subscribe to a pub I see all crap everyone is posting? What's the point? I'm better using twitter
I really like the idea of a distributed social network, but it needs a simpler, straightforward protocol. And it needs to be free of clutter.
That's just now. It's evolving fast, and two new developments will improve the onboarding problem: WebRTC-based invites, and connecting p2p to friends through a DHT (Kademlia).
Public servers were a temporary hack and nowadays most of the community is putting their public servers down. It's not a good idea for scaling, but above all, public servers connect you with strangers, which is basically undesired for a social network with a similar use case as Facebook.
There should be a pub server for each real community. I know it's not the most user friendly, but it suffices that one person in a real community of friends is techy enough to set it up, and it's not that hard: http://butt.nz/install?url=https://github.com/ahdinosaur/ssb... (this tool enables you to install your own server with a few clicks)
hey, have you tried contacting a private pub? i'm Mikey, owner of `one.butt.nz`, happy to give you an invite if you send me an email! mikey@rootsystems.nz
if you want to setup your own pub, i made an automated Digital Ocean installer (also a detailed manual) for a Docker-based pub: http://github.com/ahdinosaur/ssb-pub.
i'm also working (with funding from #ssbc-grants) on a hosted pub-as-a-service product: http://buttcloud.org.
It's not an alternative to Facebook (or even Google+) for two reasons on viability for users. Firstly, it seems to have one client in development for Android, and none for iOS. Secondly, it doesn't offer a way to use multiple devices (with activity synced). [1] This restricts the platform a lot. I've been looking at Scuttlebutt once in a while for sometime, but I don't think it's developing fast enough to be a contender.
I'd really like to have a decentralized offering, but unless it provides the key features Facebook does, like the timeline, newsfeed, groups and pages, it'll be a very hard sell to get others on board.
Okay, but the immutable references sure make it hard to get rid of stuff once you've put it up there...
I much prefer the DAT protocol, which has mutability built into its assumptions about how people will use it.
I know you could do the same thing with an immutable protocol, but Scuttlebutt is a perfect example of why immutability shouldn't be the default. Try deleting something you put on there and maybe you'll see why. I couldn't figure out any obvious way to do this. I'd imagine that's because nobody has coded the "mutability feature" for deleting posts.
Mutability needs to be built in. You shouldn't have to reinvent the wheel (mutability) every time you need it.
Beaker Browser/DAT is a much more interesting decentralized experience in my opinion.
Readit News
1. The whole Cambridge Analytica issue was caused by APIs that are too open. For distributed systems there are more ways to exploit the APIs and gather data on users.
2. There is a clear issue with Facebook's accountability in these areas. Distributed systems are typically open source, they run on multiple servers by different owners, this leads to zero accountability.
3. GDPR compliance about deleting data is almost impossible in a distributed system.
4. Some of the problems with Facebook are more about usability and clarifying how things work to users. For instance the scandal with people giving away access to their private messages. Open source software and distributed software tends to be much harder to use.
5. Any future concern/issue will be much harder to resolve if there are thousands of different instance running decentralized social networks.
6. Using AI to detect abusive content or spot fake news is much harder if you only have a subset of the data. So it becomes harder to address those concerns in a distributed setting.
So while I think this stuff is awesome from a tech perspective, in many ways it just makes these problems harder to solve.
GP points out that in a distributed social network, 3rd parties can still mine your data, you still have trouble permanently erasing information, and in fact these problems grow instead of shrink. From a user's POV, what matters is the total amount of 3rd parties over them and the leverage they have against these 3rd parties as a whole. GP's point is that shrinking FB's power by going to a distributed social network might actually increase the total power 3rd parties have over users.
Huh? Scuttlebutt is fully encrypted.. doesn't that make the API vastly more locked down than Facebook/etc?
> There is a clear issue with Facebook's accountability in these areas. Distributed systems are typically open source, they run on multiple servers by different owners, this leads to zero accountability.
This is no worse than Facebook though. With Facebook, your friend could steal all of the data you let them see. With Scuttlebutt, your friend could steal all of the data you let them see.
At least with this I control who sees my data, no? Sure, I can't have accountability with a friend, but at least no company/etc has access to my data.
> GDPR compliance about deleting data is almost impossible in a distributed system.
Doesn't GDPR apply to companies? If my mom sends me a physical card, do I have to adhere to GDPR laws with her address/name? How is that any different than Scuttlebutt?
Encryption has nothing to do with it. The whole issue with CA was that they (just as many apps before them) were using Facebook social graph data that was available for them to access via the API. Encryption on any layer has nothing to do with it - if you have access to the API, you get the data. In distributed system, if you are a node in the system, you have to have access to social graph data - otherwise the whole concept of social network does not work. You can't "see what your friends are doing" if there's no information about who your "friends" are. And if the nodes on the network have information about who your friends are - or can get that information - then they have the same access as CA (and many other apps before them) had. Facebook can at least (if they wanted to) cut off the external API and not tell the social graph structure to anybody outside Facebook. I don't see how this is possible in a distributed network.
No, not at all! TOR is fully encrypted, but there are somewhat regular vulnerability reports about various parts of the stack. Including criticial vulnerabilities that can and have been exploited by nation states, for example.
> This is no worse than Facebook though
This is not at all clear to me. The attack surface for Scuttlebutt is much larger, and I trust Facebook's security team to audit and patch much more than I trust any random friend.
Your friend can, but Facebook can scrutinize third-party apps. In a decentralized world, there's no one who has access to holistically examine automated access and detect shady activity. In a decentralized world, everything is essentially a third-party app.
About accountability: if YOU are compromised, your friends' data are compromised, and vice versa. Are you saying that the median security skill of your friends are higher than Facebook? Because any of them can leak your data unintentionally.
About encryption: it's freaking useless in this case. Remember, some people fall for Nigeria prince scam. And what happen when their keys are compromised? See above.
That's the crux of the argument: you can't guarantee that your precious friends and family can safeguard their keys (in fact, I doubt my personal security practice is remotely as good as FB or Google or Amazon or MS or Apple). In that case, by the virtual of distribution, your data is copied everywhere, waiting for any key to compromise.
1. Follow you from site to site, scooping up all the data they can on you.
2. Allowed all of that data to be accessible not just by you opening up to a bad actor app, but by any of your friends opening up to a bad actor app.
Calling it "overly open APIs" is misleading at best. The point of an API is that it is a public interface. If Scuttlebut has proper permissions controls then they wont have these problems... and because they're open source those problems can be scrutinized rather than remaining opaque.
The only solution would to be to enforce reasonable app usage in the client, and then require all your friends to use that client. That seems to defeat the purpose of a decentralised protocol.
With Scuttlebutt, largely, the client controls every one of your points. Different clients (with different settings/controls) can interact with a network upon which other users are using completely separate clients, each with separate settings controlling how user data is contributed to the network. Consent is not an issue.
With Facebook, as a user, you need to agree to Facebook's strict terms to be a part of their closed network, and—largely—cannot do so with your own client with its own data-contributing settings. The only close equivalent is using something like uBlock with your own browser, but the control you have their is very limited.
I say consent is not an issue but I'll devil's advocate myself and describe a Scuttlebutt setup where it would be. Say a company sets up a normal centralised service, which you visit in your browser, sign up for a central account, and it's backed by Scuttlebutt behind the scenes. Users of that centralised service can connect to a larger Scuttlebutt network upon which other users may be using their own dedicated clients to access. Consent is an issue for that central service (which acts as a defacto client on your behalf), but not for the network at large.Things I do care about:
-No censorship
-Chronological feed
-Open source & non-abusive client. (i.e. no tracking what users see or read)
-Good usability
I don't care about abusive content or fake news. If I see fake news, I just stop following whoever posted it.
So, under my criteria: decentralized > facebook
Isn't this asking for a bit much? /s
How do you know? Could you also tell me if my computer has virus, since you seem to have an oracle?
How about letting people make their own decision who they want to talk to, without a third party saying “I forbid it”.
The other points are just stating "much harder", which seems to just bring skepticism and little actionable suggestions.
I think there is a natural monopoly for some aspects of this, which is why Facebook is so hard to quit. But I don't think the whole thing need be in private, for-profit hands. Mozilla shows that a nonprofit can be a good steward of important web assets, with much stronger user advocacy than for-profit companies normally do.
Doing something like that for identity and interconnect between messaging and micropublishing providers seems much more robust than pure decentralization to me, which I expect would have the same failure mode as OpenSocial [1], where forces pushing toward natural monopoly are basically unchecked.
[1] https://en.wikipedia.org/wiki/OpenSocial
Who is gonna police that?
How are you gonna prevent anarchy?
Positive liberty is the distribution of responsibility to the collective (and managing/controlling the collective through central bureaucracy), negative liberty is distributing the responsibility to the individual, self organization, or stateful components in dev lingo.
Your error is that you're set on only one perspective, positive liberty, like many people in europe. GDPR is like that, instead of giving people the tools to protect themselves, and not leak data in first place, and educate them about voting with their wallets, they just take it from the individual and apply it to the collective.
That's the mindset of centralization. It's clear that decentralization efforts fail if you insist on distributing the responsibility collectively.
* ads (if using a browser that doesn't get rid of them)
* "you missed someone's birthday who you didn't even remember you were "friends" with
* look at this really popular post in your social vicinity, ENGAGE!!!
* cat/dog/food pictures
* politics of the same kind I had to ignore as a teenager, back then by mail. Sign $petition here!
* the occasional thing I give a flying fk about
This is not accidental. It is what facebook is built to do: keep you on their page, engaged. Scuttlebutt and such don't have that incentive. Liking "Pizza" or "Justing Bieber" doesn't exist. You can like a specific post, but that's not the same as putting your entire preferences on there. The possibility to digitally model your entire family and social graph and all your preferences in the open doesn't exist, simply because... why would someone implement that? And why would they then gear the UI to reward you for doing that? And it's not as inherently in danger of becoming an across-sites profile kept by a single entity.
I know you must be high school or college aged, because you didn't mention baby photos. Watch out. That's going to take over your feed in a couple years.
And if they don’t retain...how would it be useful to anyone when none of their friends are on it?
However there is no global state, users only push-pull feeds of friends and friends of friends. (In part for privacy and in part for performance, you don't need to carry all the data for a social network to be useful)
> 3. GDPR compliance about deleting data is almost impossible in a distributed system.
However that doesn't apply to individuals that aren't providing a public service.
> 4. ... Open source software and distributed software tends to be much harder to use.
Yes, however there has been some exiting discussion around what UX could become possible in a decentralized context. See https://coolguy.website/writing/the-future-will-be-technical...
> 5. Any future concern/issue will be much harder to resolve if there are thousands of different instance running decentralized social networks.
There are no instances, only peers. (Pubs are sort of easy to connect to peers and there is work being done on peer discovery to outdate most pubs; they could still be used to connect communits around topics, hobbies, etc as a way to reduce the distance between peers)
> 6. Using AI to detect abusive content or spot fake news is much harder if you only have a subset of the data.
There is no retweeting/sharing, though there is work being done on Out of Order Messaging to propagate a single message along the follow graph and there is work being done on flagging/tagging feeds/ids and posts. (Along with some semantics around how to interpret the flags/tags to improve UX and user control)
Why do you draw this distinction between "instances" and "peers"? A conventional understanding of the word "instance" would suggest it means "a running instance of the software system in question", which would suggest the word has no meaning distinct from what "peer" would mean in this context. Am I missing a critical and non-obvious distinction?
> There is no retweeting/sharing
My experience is that users really like these features.
this is cool! could you explain more?
i thought Pubs were needed to connect with peers on internal networks, to alleviate NAT traversal issues.
what i would like to know more about regarding Pubs - but could not find any info on some time ago - is how much it will cost, more or less, to host your own Pub in terms of data transfer/storage, CPU, etc. and whether rate limits can be set to manage this.
nice to see your docs.. i have them bookmarked for later :)
Although I do agree on the fake news point you make.
Edit: It seems that scuttlebutt does support optional end-to-end encryption: https://github.com/ssbc/secure-scuttlebutt#security-properti...
That was my assumption too, but I have no technical knowledge on the subject.
If encryption was used, would that keep a rogue server admin from accessing sensitive user data?
These guys really have free reign and just get a slap on the wrist WHEN ELECTIONS ARE MEDDLED WITH.
We should leave their platforms in droves to deprive them of power cause it seems like even the US Congress won’t stand up to them.
Recall that the Obama campaign got the explicit go ahead from FB to violate their privacy policy, and built up equally large databases. Heck, recall Obama explicitly endorsing Macron. Does that count as large scale meddling?
What's hilarious is that the same people worried about internet driven misinformation are now the ones jumping into action because the media told them to #deletefacebook.
No, the issue was that other people had access to data they shouldn't have. there's no problem with the API being open if only the right person has access to the right data, ie, if access management is done right
1) ... on the users that have chosen to enable this
2) ... for the users that use other peoples servers or servers from disreputable people, or share to those who do the same.
3) ... and? this presumes GDPR is a good thing
4) ... it's impossible to view a list of viewed messages, perform bulk operations, flag, sort, group etc. facebook to the same level that can be done in other 'archaic' technologies such as email. presuming commercial ui's are designed for user friendlyness rather than increasing user engagement, etc. is a red herring. also, strawman.
5) much like HTML, TCP/IP, SMTP, HTTP and everything else the internet runs on?
6) which is why spam filters don't work? and users don't have brains to do this themselves?
It's a tool. The protocol sends data peer-to-peer.
Maybe people will have to start paying the market what this data is worth, as opposed to burying it in EULAs and using venture and angel funding to create a next generation data oligarchy more difficult to overcome than any financial oppression?
And if that is not what you are implying, perhaps you could explain what it is you do think we should be doing instead.
Google and others operating a crawler would have the same data as FB has today.
Deleted Comment
This is not your usual startup launch, it's a community project by multiple open source hackers. If something is missing, you can make it happen. And there are so many ongoing developments right now (see list below), that it really doesn't make sense, at this point, to point out the current problems with the protocol. It's evolving fast, and can evolve even faster if you choose to make it your own and do something about it.
Here are a couple of things being developed:
- Mobile app for Android
- Better cryptographically-verified user invites
- P2P replication over WebRTC
- P2P replication over DHT (Kademlia)
- Better scalability (Epidemic broadcast trees)
- GitHub alternative
- "Out-of-order" replication (get messages from distant friends of your friends)
- Private groups
- Moderation tools (every person as a moderator)
- Socio-technical discussion around data accountability
- New RPC stack, rewrite
- Rust client
- Go implementation
- C implementation
- Groundwork for iOS support
- Multi-devices accounts
- Scuttlebutt on Firefox as an extension
- Overall improving onboarding and docs
- Replication over Bluetooth and Wi-Fi P2P
- Web viewer
- Scuttlebutt cloud (easy way of setting up servers)
- Websites on scuttlebutt
- etc
It's a moving target
I think these ideas will change the world for the better.
To be an alternative to facebook, it should at least do 50% of what facebook does, and it should be accessible to all.
Anything that takes more than 3 steps to get it running it's going to keep people out. And if you keep people out, you don't have a social network, at least not anything like facebook where your grandma and people you went to school with but never met (or pretend you never met) are.
Plus you need marketing, a business plan, and so much more than just code that puts people together on the same page.
I hope for a social network where the data belongs to the user, but unless you get the complication out of it... it will be just something cool but not worth the time.
It's a common mistake to attribute the success of Facebook to its features (it boils down to microblogging + threaded discussions). The usefulness (i.e. product from a marketing perspective) of Facebook isn't its features, it's the people who joined it. Look at Google+, it's not that bad in terms of features. But it lacks people, therefore it's not a competing product. A competitor would be not someone who does 50% of what FB does. It would be someone who has 50% of what Facebook has.
I use facebook only for events, groups and chat.
I am very interested in the UI/UX opportunities for training the decentralized generation how to interface with decentralized systems and manage their identities, especially across devices and contexts. This has been my biggest criticism of pretty much all of the attempts at a decentralized version of an existing mainstream web service that I have seen.
I love the decentralization community but it often feels very much like an engineer's realm, probably because it's mostly interesting from an engineering perspective. Maybe it's just who I follow, but I don't see a lot of activity in this area from user experience designers. Some collaboration could really help build a decentralized service that stands a chance of truly competing in the global space. Thus far I think it's highly unlikely the average mainstream user will convert.
What's far more compelling but challenging is open source federated social networking, which is a facebook on rocket fuel and overcomes the network effect as each provider implementing adds to a shared network. Even if it takes decades, this is going to be the inevitable model and fb will end up either joining in as a provider or do a myspace.
OK, but that's not this. Scuttlebutt is peer-to-peer, not federated. There are no servers.
I don't agree. What is the business plan of email (by which I mean SMTP, not some webmail provider)?
Of course, a protocol by itself isn't very useful. You need services using it and systems implementing and supporting it, which do cost money and require some kind of resourcing model...
Cheap cop-out. "some webmail provider" is what runs 99.999% of email. The people who run their own email, or run off hobby email servers, are insignificant.
You can't turn a blind eye to where the majority of users are going to be if you're implementing anything that actually needs traction in order to be successful.
This is such a cool thing in my eyes for parts of the world with little / no internet access. The creator of the project (AFAIK) sails around the world and, again, has little internet access. this allows him to keep people updated when he eventually does find internet.
The idea that centralized storage is the problem masks the actual concern. There is nothing inherently wrong with centrally stored data. There is a problem is when it is locked down by a 3rd party, and/or you don't control how it is used.
I'd argue that a 3rd party having the personal details and communication logs of 2 billion people is a massive problem. Privacy, governmental data requests, accidental information leakages, profiling, job applicant scrutiny, fake news, spam, data misuse by employees etc. Or even worse, in times of war.
If the store is decentralized, then any party could be equivalent to a third party, and therefore anyone has access to your data.
It's odd that we got used to the idea that "(1) registration, (2) strong password creation, (3) username selection (in case of conflicts), (4) email verification link, (5) login" is somehow a good user experience.
Cycle.js and xstream are amazing, as an aside. Thank you.
Facebook isn't an alternative to email if my grandma can't use it.
Computers aren't an alternative to telephones if my grandma can't use it.
Telephones aren't an alternative to mail if my grandma can't use it.
etc.
---
It'll get easier and simpler, I promise.
Just because things have gotten more complicated and people have used them doesn't mean that people will start to use any complicated thing.
For example:
Google+ / Google Wave isn't an alternative to email if my grandma can't use it.
GPG isn't an alternative to talking in-person communication if my grandma can't use it.
... etc
Yes, you have valid examples where things that are relatively complex did become popular, but there are many many more examples of things that were more complicated and failed.
Just because scuttlebutt is complicated is not a reason it will succeed, but is indeed a valid reason it might fail.
Arguably it isn't FB if regular college kids can't use it. If they can subsequently onboard less tech savvy people, so be it, but that could be a future goal.
I wonder if Facebook is perhaps just not worth it.
The idea was interesting, the UI was pleasant, and I could see this working at some tech conference where people connect with each-other and there's a common pub server so people can keep in touch afterward, but I don't see uncle Joe or grandma using this thing over FB.
I really like the idea of a distributed social network, but it needs a simpler, straightforward protocol. And it needs to be free of clutter.
There should be a pub server for each real community. I know it's not the most user friendly, but it suffices that one person in a real community of friends is techy enough to set it up, and it's not that hard: http://butt.nz/install?url=https://github.com/ahdinosaur/ssb... (this tool enables you to install your own server with a few clicks)
if you want to setup your own pub, i made an automated Digital Ocean installer (also a detailed manual) for a Docker-based pub: http://github.com/ahdinosaur/ssb-pub.
i'm also working (with funding from #ssbc-grants) on a hosted pub-as-a-service product: http://buttcloud.org.
I'd really like to have a decentralized offering, but unless it provides the key features Facebook does, like the timeline, newsfeed, groups and pages, it'll be a very hard sell to get others on board.
[1]: https://www.scuttlebutt.nz/faq/applications/multiple-devices...
I much prefer the DAT protocol, which has mutability built into its assumptions about how people will use it.
I know you could do the same thing with an immutable protocol, but Scuttlebutt is a perfect example of why immutability shouldn't be the default. Try deleting something you put on there and maybe you'll see why. I couldn't figure out any obvious way to do this. I'd imagine that's because nobody has coded the "mutability feature" for deleting posts.
Mutability needs to be built in. You shouldn't have to reinvent the wheel (mutability) every time you need it.
Beaker Browser/DAT is a much more interesting decentralized experience in my opinion.