lol what? So we should learn nothing from the cool stuff others have built because they got some good PR? Come on, that’s absurd.
Also, users don’t choose to use a product just because it got a few mainstream press stickers, they certainly don’t stick around because of it.
Yea it perpetuates a movement, but articles talking about how there’s 1M users or whatever come after the 1M users….there was relatively little coverage between when they launched and a month or two ago, during which time they got 1M users. Blaming “the media” for losing users to competition is so lazy.
I don’t really understand this kind of criticism (and not to pick on Will here, it seems to be from ~everyone).
Bluesky took a different approach - first build a product people want whose technology supports decentralization, and add the features the geeks want later. It’s easy to shit on their lack of decentralization, but Bluesky has made clear and consistent progress on that front since day one, and I assume they will continue to do so.
The result has been a product that’s growing (those user stats are pretty realistic, doubly so when you look at the number of accounts actually posting real content) way more than nostr with tons of anti-centralization features that nostr is missing (anyone can create a feed algorithm, and there are many, decentralized content tagging is a really cool innovation - different “adult content” tagging services, opt-in different moderation services, etc).
The federated model of Mastodon led to a trainwreck of fiefdoms run by weirdly obsessive and controlling mods, but Bluesky took that and addressed the issues by splitting moderation from hosting.
Sure, Bluesky’s hosting model means you don’t get the relay-redundancy that sets nostr’s censorship resistance apart, but that’s not all that hard to add in the future (with the sync assumption they make making it easier to make efficient, too).
Building the kinds of stuff Bluesky has on nostr is gonna take a huge investment, we can’t leave folks like Will stuck building critical nostr apps by himself. nostr:note1vpteqdxxlgkjndhghhlu4n47aj2sra5vgmdr465y4yfzwcshglvqrqann4
See that’s not true. They have actually made material progress towards their decentralization goals and suggesting “it’s just Web 2.0 centralized crap” is just being intellectually lazy.
Except that’s not at all what they’ve built or what they’ve built towards. The whole point of Bluesky is that they separated hosting from moderation/censorship. Their goal is that individual users can select what they want to see or not see (which you may agree or disagree with as a design principle), which they’ve made great strides towards. I suggest you dig a bit deeper into how it works before you criticize it further :).
Yea, sustainability is definitely a big question, I assume at some point they’ll have to add ads (or a premium option) like everyone else. If they manage to redundant’ize the hosting before then (assuming that’s something they want), though, they may end up just eating all of nostr’s features….
Meh, every protocol starts with one client. That doesn’t mean progress hasn’t been made (most of the backend stack can be self-hosted with all the same data as the “official” backend, except one part AFAIU, which required a lot of work), nor that more progress won’t be made.
Yea, Bluesky has moderation, but that doesn’t mean it’s some centralized censored crap - especially if they manage to decentralize further and lean into the decentralized opt-in moderation design they have!
Hmm, the did resolution part isn’t all that critical to the overall system, DID creation is basically just adding a DNS/HTTP record. I guess I don’t really understand your concern here, tbh.
Much of it doesn’t actually need to be run to decentralize. “Labeling services” are basically just entities publishing messages to add tags to users (for blocking/adult content/etc), so you can just skip that and not block, or someone can just run that part and you can “subscribe” to that with your own server for the rest…
Also the UIs are on there and obv that’s just an app.
Finally….. currently much of it is one “docker run” soooooo
Basically their architecture is “the thing that stores your posts” separated from “the thing that an app contacts to ask for which posts to show in the UI”. The first is trivially run today and federates no problem (ofc that’s easy). The second is runnable but hard just because of size. I don’t see why no one would run that, though, at least if you think nostr relays are sustainable.
All it takes is one person to stand up and build a new app with a different server and that goes away. It’s very centralized in practice today yea, but that can change fast…..or not. Depends on whether someone pushes it.
Yep, basically that. They can choose to push it in the future (eg if they run out of money), or might not. Given they’ve gone a lot of work towards it I assume they’ll at least try, subject to potentially limited budget.
But in the mean time they added a lot of decentralized features that have lapped nostr in some domains (anyone can create a feed algorithm, even if it’s run centrally, is huge! Same for ban decisions being shared lists).
Bluesky’s separation of moderation from hosting does reduce the chance of that pretty substantially. Unlike mastodon, where everyone is constantly screaming for servers to block each other, users can opt to do so without the operator taking that decision. Sure, the operator could as well, but the fact that they don’t have to (even if they think the content is objectionable) is pretty important imo.
But the only thing that sets nostr apart here is that clients connect to multiple servers. That’s….a very simple feature to add to any social protocol? They could just add that and be done with it and then we’d have nothing. Not sure they will, but…
Bluesky separates the concept of the server that hosts your posts from the server(s) that clients connect to to fetch posts to display. The second group of servers intends to connect to every possible first group and download everything. It’s not like nostr where relays don’t sync.
Sure, but the only difference between that and nostr is clients defaulting to connecting to more than one data hub. It’s big in practice, but to suggest we should dismiss Bluesky out of hand and not bother to learn from the cool other stuff they’ve built because of that one difference is…. Weird?
The “relay” is an optimization and you can run your own. I think you’re confusing it for the actual data store, which can also run your own though indeed no one does. Maybe your info is out of date?
I don’t think anyone is suggesting that Bluesky’s decentralization is here or substantial. It might be in the future, but it certainly isn’t now. The point is more that we should learn from their feature set, because they have some features that are very decentralizing of power within a social network, even though they run on centralized rails.
The ability for anyone to create a feed algorithm and share it directly as a post is the most obvious huge one. Decentralized opt-in moderation/spam filtering/tagging/NSFW-marking is the other.
How is this materially different for nostr relays? Sure, nostr clients connect to a few relays, improving censorship resistance greatly, but generally nostr relays are expected to have a large majority of all notes in the social context.
The comment about relay being an optimization was somewhat nitpicky, you’re just using the wrong term (technically the relay is a proxy between all the PDs’ and the app view, the app view stores all the posts too and you could drop the relay and replace it with the app view(s) connecting to all the PDSs directly).
The “App View” is a server that returns the posts to display in the feed to clients (eg the mobile app). In practice the App View is what *has* to have a full copy of all the tweets, much like a nostr relay works in practice today.
Clients simply making the same request to multiple App Views wouldn’t result in having to rewrite or throw anything away, I have no idea why you’re suggesting that - in general you’ll get the same response from each, just have to merge them on the client side.
But really I do not at all understand your comment here - literally the Bluesky devs encourage other relays to exist, and other people *do* run relays, just not very many because of the overhead. Suggesting that they view multiple relays as a bad thing is…. strange to me 🤷♂️
AFAIU you can have an App View that uses a relay, but could also be one software package. conceptually for the purposes of this discussion it’s really one thing.
Making the assumption that every relay is going to see ~every post is very much not the same as assuming there will only be one relay. You’re just putting words in peoples’ mouths, then.
Yea but in practice (a) clients mostly don’t, and for very good reason - probably you don’t want to leak your IP to everyone you follow and (b) the number of people with their own relay is very small, instead most users rely on some relay existing that will host everyone’s crap for free.
Not sure there’s much else in that post? Only other point you made is that the only other relays are mostly for hobbyists stuff, which I think is mostly true. Don’t disagree so why respond to it :).
I don’t *think* it will necessarily become properly decentralized, but rather that it totally *could* and they are working toward it (whether they run out of resources before they get there I dunno), thus I think dismissing Bluesky as “not decentralized, next” is naive.
But I can tell you for sure there the “custom feeds” feature, at a minimum, led to substantial early adopter/evangelist momentum. To a much lesser extent the decentralized labeling/moderation/censorship feature as well.
Even if they didn’t drive material user adoption, they’re cool features we should be learning from, not dismissing the whole thing “because it’s not decentralized”.
IOW there seems to be a string desire on here to dismiss Bluesky for trivial reasons (“not decentralized”/“they got MSM coverage so the user growth doesn’t mean anything”/etc) rather than admit they’ve built a product that resonates with a large number of people and that has cool features we should learn from!
Really? His claim is mostly that there’s this clear consensus for various protocol changes for Bitcoin that aren’t happening because of “lack of leadership” in Bitcoin Core. But I’m really really struggling to see where that consensus is, and for what it is.
There’s nothing that requires someone contributing to Bitcoin Core regularly to lead the charge for creating consensus around a protocol change, and I’m happy others are trying, but nearly everything I’ve seen people pushing is just very very clearly not at the level of consensus yet.
That doesn’t imply that somehow Bitcoin Core contributors are at fault (or responsible for creating consensus around other peoples’ ideas), maybe the ideas just aren’t mature yet.
The dynamic he’s describing (where you have to convince “Core”) strikes me as an incredibly weird way of viewing it, though - it’s just a group of developers working on one project. I don’t really understand this perspective at all, tbh.
In terms of “well why didn’t CTV happen”, I responded on Twitter, but there’s nontrivial risk to the act of doing a fork in Bitcoin. That has to be weighed against the value of any fork. For me personally, I didn’t see a single use for CTV that was even remotely compelling (not like I wouldn’t use it, but I don’t think anyone will use it) until Timeout Trees, at which point every has given up on CTV.
I don’t think “well clearly we’re just not getting anything” is the right way to look at it. From where I sit, the attempts at adding covenant features to Bitcoin have been half-assed at best.
Huh? Yea it is rather easy to set up a server for bluesky, did you read the docs?
That said they’re not quite the same - clients don’t connect to multiple servers like they do in nostr (saving a ton of bandwidth in exchange for the server they’re using being able to censor), and the default server just serves your content, it doesn’t index other servers’ contents so you can use that to build your own feed (like nostr in that regard but more important in bluesky).
And yet it’s growing at a rate that nostr isn’t. Sadly “supports an algorithmic feed” seems to be a pretty important feature if you want users to join a social media platform. Luckily nostr could support such a thing, but we have a lot of catching up to do.
I assume this will be misinterpreted - not saying the Dems were fated to lose through no fault of their own (they’re generally left of the American public in ways voters don’t appreciate, and that’s part of what they paid for) but those celebrating bitcoin-minded voters or a rightward swing because voters decided for those policies (rather than just mostly want to not have inflation) are also overly exuberant. nostr:note1sddxmdeps5mk3yz08ayqmfnjkty0adfcay7x9gnnzmnyjtrs8y0q2nz8pa
Not that Kamala wasn’t a pretty poor candidate or that Trump didn’t generate excitement, of course, but the economy is a *really* strong headwind in any election. Don’t overread the general populace’s desire to “vote crypto” or for any other specific issue. nostr:note1vpzh0nc6hrmvzhkc2alztlj5gcc5yh62at9h63plx7ddsay40rfs63td56
A lot of the “Trump won because….” takes feel incredibly US-myopic. This was the year of more democratic elections across the world than almost any other and nearly all of them “surprised” in how strongly they voted against the party in power (both left and right). The universal rule of politics remains undefeated - people vote their pocket books.
(Not that Kamala wasn’t a pretty poor candidate or that Trump didn’t generate excitement, of course, but the economy is a *really* strong headwind in any election, one that’s nearly improve to overcome)
You’re more likely hitting hardware issues that only crop up when running the machine hot. Try running y-cruncher and memtest. Similarly try testing your disk (don’t know any applications that test if it corrupts at high rate, I know they exist tho)
Private gossip efforts kinda stalled without a champion, sadly. Gossip v1.5 is mostly redoing gossip so that we can do taproot channel announcements and also minisketch the gossip sync protocol. It also theoretically supports announcing more aggregate channel capacity than UTXO proofs provided but unclear whether people will implement that (especially on the announcing side).
Ideally someone with a bit of time could sit down and spec out (and then implement) log-scale ringsig announcements, but I’m not sure it’s gonna happen soon on its own.
It’s kinda funny that there’s now legal betting on US election outcomes on CFTC-regulated markets through brokerage accounts but you can’t place the same bets at a casino.
No no, for offers. Imagine Nostr app wants to zap using BOLT 12. It does a system open for bitcoin:?lno=lnoffer&pop=proofcallback, but it ultimately needs the proof to include “Bob zapped with emoji🫠”. So either the proofcallback has to include the private key or that original URI has to include the string to sign.
I think it’s required. If we’re flipping it to have the nostr zapper broadcast the zap (which we should) you need to cryptographically tie the nostr zapper to the payment proof somehow.
I can see the argument for returning the key explicitly (it’s simple, the initiating app is the payer, kinda), but it feels pretty gross (two copies of a key always bad if you can only have one). Seems cleaner to just pass the message in the original URI?
The web client shouldn’t be fetching the invoice, it just passes the whole offer on to the wallet and asks it to pay. When the wallet completes it does a callback to the initiating app.
Admittedly I wasn’t really thinking about web apps in the above design though. Nothing specific shouldn’t work except that the spec explicitly says wallets can’t open a callback URI that has a scheme of http(s). I was worried about it being a way for a payee to discover the payers IP, but I think maybe it doesn’t matter.
I’m incredibly, incredibly skeptical that with the amount of data we’re talking about you can even measure the difference in performance on a LAN, let alone the internet.
AFAIR QUIC has the same number of round trips as normal TLS if you set the TCP options right. Basically it shaves off RTs because it begins the TLS handshake in the SYN. You can do that with TCP, too, doubly so if you aren’t using a TLS library that sets socket options for you. The claim in your diagram that you need 0 full RTs to do QUIC setup is nonsense, that’s just if you’ve spoken to the server before and it has cached keys, but the 0 RTT TLS stuff isn’t being implemented in generic HTTP stacks because of replay issues.
TLS’ only issues aren’t just CAs being a mess, it’s also an anachronistic protocol that just isn’t how you’d design something today. 1.3 is better, sure, but it carries tons of legacy garbage and most clients still have fallbacks and logic for it.
I also dislike QUIC for being a lazy, poor version of TCP. Middleboxes suck sometimes but sometimes do useful things (eg on a plane TCP is terminated before it goes to the sat, improving latency and throughput compared to UDP things with retransmissions, middleboxes can use MSS clamping to avoid fragmentation, etc). QUIC largely failed to consider these things and just said “screw all middleboxes” (compare to eg tcpinc which got similar encryption properties without being lazy). QUIC exists to rebuild TCP in user-space cause kernels sometimes suck, but for those of us with an operating system newer than five years old that’s not a problem we have. Worse, sometimes your OS has specific useful features (eg MP-TCP) that you don’t want twenty apps to have to rewrite. FFS this is literally the point of having an OS! The only promise QUIC made that isn’t as trivial in TCP is FEC, but they gave up on it cause…I dunno why.
Note that QUIC is useful on the web for helping to and the multi-connection/head-of-line blocking problem. But if you aren’t fetching a bunch of resources from the same server across different streams where you can use each resource individually on its own this doesn’t apply (and it requires integration work to make it apply).
I mean if you drop the TFO requirement it’s easy - just open many connections. But just fetching many resources isn’t sufficient to want QUIC - you have to be doing so immediately after opening the connection(s), the resources have to be non-trivial in size (think 10s of packets, so the text of a note generally doesn’t qualify) and have a need for not blocking one on another, which is generally not the case on a mobile app - server can send the first three things you need to paint the full window first and then more later.
It’s just a head-of-line-blocking question, though…I imagine mostly you’re not downloading lots of CSS/JS/images, which is the big head-of-line issue HTTP clients have - they can render the page partially in response to each new item they get off the wire.
I assume you don’t, really, though? You presumably get events back from the server in time-order and populate the page down in time-order, so mostly one event stalling the next won’t make all that much difference in UX?
I think the difference is that with ecash the buyer choose who to trust and only trusts them. With your setup the buyer needs to trust the seller to some extent to use their infra to log into a custodial wallet. I’m not sure that’s a great idea.
At least directly with lightning, it’s not immediately obvious how you could reveal a key that only allowed you to spend up to some limit. The normal setup in lightning is your key can sign for the whole 2-of-2 channel balance. With pre-setup you could have some extra output on the commitment transaction and a new sub-channel that you could give the recipient control over, but you’d need to have that set up in advance for the exact amount you want to send (and it’d be a fairly complicated protocol extension for everyone to support). Probably just use ecash for the initial minute and then pay with lightning for further minutes after you’re online.
Yea, you can do multisig channels (indeed nested musig) for lightning (well, 66%+1, not 50%+1, sadly), but you’re still doing the “I communicate with some third party over your internet before I pay you for it”.
But, yeah just giving people a tiny bit of internet works fine mostly. Even airplane WiFi with credit cards lets you access DNS before you buy…
Oddbean new post about login | logout
Notes by matt | export