Amen. It's a strange combination indeed, and a reason why I took down the SSB "pub" I was self-hosting on NetBSD on an OrangePi Zero for some friends, back in 2020.
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.
If you don't want to store people's data, then an SSB "room" server is the option, and in fact is the best type of server currently serving the SSB network. More info here https://www.manyver.se/faq/admin-room
Once you share something on the internet, its potentially there forever. You can only make it more difficult to be found. If its controversial, the chance of it getting copied (e.g. screenshotted) is bigger. There's a name for it too: Streissand effect.
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.
In snapchat, you're sending messages to friends, or at the very least individuals, who you trust have not rooted their phone to log messages.
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
And that brought us to the world of a thousand broken links, threads becoming dead graveyards after a few months, and people archiving threads using screenshots. The current internet is terrible at archiving anything.
there is a big space between archiving anything and archiving everything.
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
I would prefer a world where people only shared things they were confident would not be embarrassing or hurtful later. It wouldn't be as popular of course.... just wholesome and friendly.
Seconded. The onboarding is so terrible we just gave up after failing in every possible direction. Nothing worked.
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.
(I develop Manyverse) Onboarding in SSB is invite-driven and thus is at odds with safety. If you want to "find people" easily, and easily join the network, then this means that any harasser can also do the same. Improving Onboarding while not sacrificing Sustainability and Safety is my top priority and there are several protocol advancements being worked on, more information here: https://gitlab.com/staltz/manyverse/-/wikis/Starchart/
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.
> Feels like it was run by an in-crowd, with no strong interest in new users.
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.
As a long time patchwork user —April 2017 for the win…— that just recently quit, I could see how the multitude of half finished clients, deprecated functionality would get to that outcome.
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%."
What makes you think it is dead when there are active users every day, development is active, and there's a developer conference this week (https://p2p-basel.org/)?
That's a very limiting definition of 'death' and it may as well have applied for "Linux Desktop", yet Linux as a Desktop choice is increasingly popular, just not at a growth rate that would satisfy Silicon Valley: https://www.justingarrison.com/blog/year-of-linux-desktop/
As for 1: you don't have metrics for that. As for 2: you don't have metrics for that.
I wish you all the success with your grants and crowdfunding. We disagree with the feasibility of ssb as a platform, but either one of us trying to sway each other from their position may prove to be a foolish errand. Fair winds.
Onboarding wasn't as bad as your recent experience when SSB first started. You just jumped on the same wifi router as your peer and the feeds sank, or got a pub invite and the feeds of the pub's friends were sent to you.
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 »
The points in that article are completely irrelevant and inconsequential.
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.
> 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
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.
Just because it's inconvenient enough for employers to check that they currently don't doesn't mean that it will stay that way. Digital archives generally get easier to access over time.
Probably should but in practice won't be for most people. The people who have party pictures that are wild enough to be a problem are probably even less likely to evaluate the probable threat landscape for the next decade or two before posting. It's nice to be able to easily fix things like that after the fact, at least in most cases.
What I meant was that maybe we should discourage everyone to be “one person” online and rather encourage using multiple different identities and especially not posting party pics (or anything personal) under real names.
Maybe we shouldn’t use real names at all on the web.
> because as soon as you has shared them with a third party the control is out of your hands anyways.
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.
Solution: sign every log entry with its own key. To repudiate an entry, publish the private key you used to sign it. But of course, it needs to be baked in the protocol from the start.
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.
Another problem with that; time. You publish the key after you sign and post the message in question. It's tough to prove 100% but you're only really invalidating posts from after the date you publish the private key.
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.
Solution: publish every private key after, say, one week.
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.
The recipient knows you sent the message, because they received it before you published the key. Nobody can prove you sent the message, because they received it after you published the key, and even if they did receive it earlier, they can't prove it in court.
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.
Many well known archiving sites will attest that you made the post after it's deleted. If they don't, then random trustworthy individuals can do so instead.
> You can "delete" things in an append-only ledger, in the sense that you can update the state with e.g. a tombstone marker.
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?!
A Tombstone in a signed log is not the same as "marking an entry as deleted", it's replacing an entry with something that contains enough data to maintain log integrity. E.g. "this tombstone replaces an object that had the hash XYZ".
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.
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.
Any p2p service requires the various partecipants to download each other's content. This means any change you make to your content will not necessarily be mirrored to your followers, depending on the client they are using. It's not something you can enforce at the protocol level, unfortunately.
With p2p more than with anything the age old adage of being careful with what your publish online is true.
This have been on my mind recently about secure decentralized systems... but how do the devs cope with what they are doing would be most likely used for criminal stuff? And I'm not talking about pirated movies here. Feels like there is an idealistic view on secure tools ("we help people to rise up against regimes!", "say no to megacorps!") but in reality a huge chunk of use case would be straight up criminal. Make no mistake I'm not arguing against encryption or security, but still I'm thinking about this recently that how open source a lot of time ends up being used for very bad things and how might this can be mitigated. Or maybe we should just accept this as a necessary "side effect"?
When you make a general purpose tool, sometimes people use it for harmful things, but the overall effect of telephones is clearly positive.
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.
You are raising a valid point, which does affect people who do work on encryption, security and protocols in general. You have to figure out if you think it's worth it or not.
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.
if i remember correctly the printing press was banned for a long time in turkey because they believed that would cause death to hand calligraphy workers. that might've been a good argument but the idea was more insidious. people would get fast access to knowledge and the government control would get less and less to what they could control.
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?
Manyverse is cross-platform and it's the main desktop app nowadays: https://manyver.se
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.
Hey, André! Good seeing you here. I love your work!
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!
I was bullish on SSB and it was definitely a cool experiment (completely decentralized; doesnt even need a server, p2p social networks!) but at the end of the day, if those "benefits" are not explainable to the layman (or not even benefits) then it's never gunna succeed. Most of us are online all the time, and don't need a fully offline-first social network. I'm now much more excited about mastadon, though I dont really use any public social networks myself. Social networks amongst my friends have been replaced with group chats via Signal and Whatsapp.
That's the big issue with basically all decentralized services, they usually have some additional headache from the decentralized architecture but the actual benefits over a centralized service aren't relevant to even the average technical user. Mastodon didn't really take off until the moderation and social environment at Twitter got so twisted post Musk the benefit of being not Twitter was nearly enough to get people to switch. Even then the day to day of using Twitter may not have changed for most people, it hasn't that much for me but I have a pretty curated follow list.
Sorry to not write like a sms addict. I'm old school. And yes I found in SSB a efficient tool that meet my wish in social media. And I'm a bit upset when I see closed mind critics. SSB lives with no money or so few. But I see so much people happily trade their life for no brain needed tools that I find it disappointing.
This inspired Nostr which seems to be all the rage lately https://nostr.com
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.
Nostr will be a widely adopted protocol within the next few years. A social network with a built in payment system will be very useful in places like Africa, South America, etc. Americans will most likely miss the boat, per usual.
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?
Not storing media sounds odd (prone to linkrot), but I guess this feature is likely optional?
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.
> This inspired Nostr which seems to be all the rage lately
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 really loved ssb and even ran my own instance at one point but found the reference implementation hard to replicate based on the documentation at the time and the network itself seemed somewhat unscaleable. As I recall, your client keeps a full record of posts and so after following a modest number of people my local storage grew to several gigabytes. When I was running the server, it needed regular restarting to keep things operational.
85 comments
[ 3.7 ms ] story [ 179 ms ] threadAsk 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)
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
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 »
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.
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
https://en.wikipedia.org/wiki/WASTE
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!
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.