Secure Scuttlebutt
en.wikipedia.org
en.wikipedia.org
Ask HN: Anyone got experience using Scuttlebutt? Thoughts? - https://news.ycombinator.com/item?id=29974051 - Jan 2022 (4 comments)
Scuttlebutt Protocol Guide - https://news.ycombinator.com/item?id=29672518 - Dec 2021 (35 comments)
Scuttlebutt: Decentralised, off-grid, mesh network and self-hosted social media - https://news.ycombinator.com/item?id=28612591 - Sept 2021 (3 comments)
Scuttlebutt – A decentralized secure gossip platform - https://news.ycombinator.com/item?id=25713830 - Jan 2021 (164 comments)
What Is Scuttlebutt? - https://news.ycombinator.com/item?id=22915460 - April 2020 (40 comments)
Scuttlebutt, a Decentralized Alternative to Facebook - https://news.ycombinator.com/item?id=16877603 - April 2018 (342 comments)
Patchwork – Decentralized messaging and sharing app built on Secure Scuttlebutt - https://news.ycombinator.com/item?id=16273096 - Jan 2018 (64 comments)
An off-grid social network - https://news.ycombinator.com/item?id=14050049 - April 2017 (366 comments)
And the message is “other clients should take it from here”.
https://github.com/ssbc/patchwork
However it’s still the first and recommended one at the website.
https://scuttlebutt.nz/get-started/
I don’t think I have time for this.
I don’t think this is for me.
I guess I’ll go back to trying to decipher Urbit. I kid, I kid. (I still have GNUnet to decipher.)
The Scuttlebutt.nz website hasn't been kept up-to-date. SSB's development is also decentralized, so this means that not everything moves forward in unison, so depending on who you ask, Scuttlebutt.nz is not the official frontpage.
… oh I get it, it’s decentralised, there is no official front page?
Anyway yeah Manyverse seems to “work”, in the sense “is up to date, I can run it if I ignore the OS X insecure errors, and I can even join a server”.
But the one server where I could get an invite has 0 posts and 0 people apparently so, I need to keep digging I guess
Then I guess this really isn’t for me.
I’ve been one of your supporters (via Patreon) for several years now (I literally have your name somewhere in my monthly budget — haha), and I will continue to support you, even though it’s not a large amount of $.
I sometimes wish I could work on open-source projects I love full-time, but instead I get to live vicariously through awesome folks like yourself.
I hope all is well with you. Keep up the great work!
The distribution idea is glorious, but we'd all be better off with an application like it built on top of Syncthing ( https://syncthing.net/ ), ala DecSync ( https://github.com/39aldo39/DecSync )
You can "delete" things in an append-only ledger, in the sense that you can update the state with e.g. a tombstone marker.
On a higher level you can't delete things anyways, because as soon as you has shared them with a third party the control is out of your hands anyways. Just because current social networks try to hold up that facade doesn't make it a reality.
Sure you could make tombstoning past messages and making their contents inaccessible a more central feature, but there is nothing inherently wrong with append-only social networks.
Most things are readily forgotten once removed. No one cares enough about someone like me to keep a public archive of everything I've ever posted anywhere.
Maybe we shouldn’t use real names at all on the web.
Caches and archiving sites do exactly this.
If I delete something from FaceBook, there's no way anyone (other than FB) can prove that I have said the things I deleted. With a signed append-only log, you'll have to disown your entire log and your keys. This is the problem.
B: You can't prove that I said X! Here's where I published private key used to sign that message.
A: Do you normally publish the private keys of your messages?
B: No
A: Okay, while I agree I do not have cryptographic proof that you said X, I think it's extremely likely that you said X and then later attempted to retract it by publishing the private key. So I'm going to go ahead and act as if you said X.
It also doesn't solve another part of the problem with append-only, accidental oversharing. Even if we take this 'publish the keys' process as actually working the data is still out there so if you publish info you shouldn't like locations or PII it's always out there.
That's true no matter what, purely by virtue of being shared with others.
I believe there are point-to-point protocols that publish every private key after the recipient receives the message, but I don't see how it generalizes to publish-subscribe.
I'm missing something..
That's why the key should be published as soon as possible. In a point-to-point protocol, it would be published as soon as the recipient confirms receipt of the message. That's why I'm not sure how it generalizes to group chat protocols.
Since when is deleting the same as marking deleted?! I have a piece of rubbish on my desk, so I'll just mark it in my head to throw it in the bin, and done?!
The problem that remains is that for everyone who doesn't follow the tombstoning request and keeps the old value, they can still "prove" that what they claim was the original value is correct because its signed, unless you do more complex stuff with non-repudiation constructions etc.
That's the part that's not possible with an append-only ledger.
The article you linked is full of misunderstanding of the technology anyways, just because the underlying tech is append-only, doesn't mean you can't delete stuff from your local store or hide stuff you don't want to see.
With p2p more than with anything the age old adage of being careful with what your publish online is true.
Feels like it was run by an in-crowd, with no strong interest in new users. Keybase has similar goals, but was super easy to get started in.
It's such a shame as I really like the underlying ideas. But the implementation is hopeless and the way it's presented on their website is downright icky. Honestly, the video "explanation" of a love story with Scuttlebutt weirded me out - it was more like some weeb's fantasy of what a love story would be like rather than any kind of useful intro into how you'd use it.
And we could get on to the network and join pubs. Only there was nothing in there. We should also have been able to invite each other and follow each other's posts, as we were both using devices on the same wifi, but that just silently failed.
A week or so later the iphone app rolled out an update with a patch note saying something along the lines of "whoops, new signups went to the test servers instead of prod by mistake" which _may_ explain some of it. But going back in to the app after the fix was no better.
My more charitable interpretation of the experiences I had when trying it out was that they are stuck in a never-ending refactoring state where they are always in between the "old" and the "new" system, and you have to be very up-to-date to know which are the compatible beta versions of all packages (which can't be a good experience for existing users either).
-----
I do like SSB for it's conceptual approach of trying to model existing social realities in technology rather than trying to build a technological model of communication and making humans conform to it.
In practice however, I think it has been superseded with ActivityPub and Matrix, which build on very similar core primitives.
SSB is dead, other than the few trying to make a go financially at it, via either crowdfunding, NLnet grants, or VC.
I've reverted to Web 1.0 blogging, with none of the bs that is consistent with using a archived client, focus on trying to fit a database into a mobile app — without regard to front end functionality.
> When I look at Beaker, I think it was probably 50% easy. The initial demo took 2 weeks: 20%. It was a full website editor in about 2 months: 30%. The feedback was great: 50%. The users didn't stick: 50%. We got invited to talks which increased exposure: 51%. A few niche communities took an interest: 53%. Folks liked it enough to donate via OpenCollective and Patreon: 54%. You get the idea. Notably absent is "usage and retention went through the roof: 80%" and then "usage continued to grow for years: 100%."
Everything that pfrazee wrote here about Beaker Browser at https://github.com/beakerbrowser/beaker/blob/master/archive-... is true for ssb.
1. it hasn’t grown past the early adopter phase 2. There is no product-market fit.
The evidence I have is the litany of dead accounts that follow my account. Luckily, via mastodon I’ve been able to reconnect with those people.
As someone else has mentioned mastodon is doing quite well. And from experience Web 1.0 blogging is a breath of fresh air.
The Nile is not just a river in Egypt.
As for 1: you don't have metrics for that. As for 2: you don't have metrics for that.
It could work that way again, you just have to emulate the original experience and get rid of all the weird broken stuff that's been added to make it hard to sync posts.
@evbrogue I’m not sure if you know of the current tech stack direction… meta feeds so you have a blockchain of off blockchain content. This is the delete « fix »
Nostr is self-signed (and optionally encrypted) "notes" that are passed around using "dumb relays" it's a pretty cool concept, and it has attracted a lot of active devs/projects.
From the protocol README section "The problem with SSB (Secure Scuttlebutt)" - it lists a few small things but is mostly complimentary of SSB. One of the big issues I always had with SSB is efficiency/scaling/message size/db size. Is this something Nostr addresses or considers, or is it likely to suffer from similar scaling issues with heavy use?
* Media itself is not stored, only links to media.
* Relays are free to limit usage, charge a fee or require proof of work.
* There are many kinds of messages with different storage standards i.e ephemeral messages are not stored at all.
I'm not an expert but the SSB scaling issues seem related to the architecture being tied to the sigchain, & general feed immutability. This makes it very difficult for pubs to, for example, accept/process subsets of posts or do anything out-of-order. It also makes it impossible for clients to limit local database storage, especially mobile clients where that might be at a premium.
Even just the existence of ephemeral notes seems to indicate there's no such architectural limitation so that sounds really hopeful.
Lately for me seems to be since last week, at least on Twitter. People started promoting Nostr whenever someone mentioned moving to Mastodon. The posts associated with the hashtag #nostr seem to be directly or indirectly associated with cryptobros, a significant red flag.
I don't want to store other people's dataz even if encrypted, and I certainly don't want to have everything I shared being available for eternity, or to have to switch identities periodically.
That's why Snapchat provides a false sense of security. On a rooted smartphone the privacy feature of self destruct does not work, and there's always the analog hole. There's extensions for platforms like Reddit which show supposedly moderated/deleted content.
Anything put to the public internet is there forever because antisocial corporations and the few individuals who do not respect privacy can operate at scale.
Asking a normal person nicely to delete something almost always works though, especially if not deleting it is a hassle
Snapchat style messages completely solves:
- someone you trust now later becomes untrustworthy and would use old messages against you
- messages are stored on your phone and can be found by someone else later
neither of these can happen if deleting messages is not an expected and normal part of the protocol
it does not solve the problem of sending messages to someone who already wants to hurt you (ie. the public internet)
I am not negative to the idea at all, there is probably interesting use cases where keeping (for audit or attribution or whatever other objective) such decentralized logs is useful. But some of these needs might be served eg. using git, whereas others might beyond the reach of users because (while its 2023) it is still a hassle to self-host
On the other hand, when you make a decentralized encrypted tool in a space where other options already exist that handle the most common non-criminal use cases your balance of how much you are facilitating harmful vs beneficial use is pretty different.
This doesn't mean that you should never create secure distributed tools, but it does mean that the trade-offs around them look pretty different from something like traditional phones.
In the distant past, I was working on technology that aimed to avoid any sort of government control or inspection, and we frequently had in mind that what we were building could be used for bad just as much as it could be used for good. Ultimately, we decided it was worth it, after weighing the good against the bad.
the same could've been said about telegraph or telephone when they first came out.
telephone has been online for around 100 years or 150? it is centralized, every country IMO has wiretapping laws for law enforcement agencies but has that stopped criminals from using the tech?
email must've felt the same, IM too.
why should centralization be the panacea for everything?
tomorrow android will be used by criminals to build their own crimeOS that is built on android><lineageOS and it is the single biggest criminal sindicate doing very nasty stuff. should android and lineage devs be concerned if a section of their users use it to build their own crimeOS that is made to evade police? more importantly, how are THEY responsible?
one can argue, "well they should be responsible for their software if it falls into the wrong hands so they should build some sort of protection or backdoor for genuine law enforcement agencies".... would'nt this argument apply to knife makers too? what will they do? make you use the sharp edge in kitchen only by using NFC tags on the chopping board?
I consider dragnet surveillance to be more harmful to society overall than the existence of sex and drug trafficking