In transit, I’ll be toying with the git2 crate in Rust, trying to propagate the experimental sha256 feature flag from libgit2. The stacking of build systems here is a bit messy, and it seems like a bit of upstream untangling to do it right.
…the Bluesky people were looking for an identity system that provided global ids, key rotation and human-readable names.
They must have realized that such properties are not possibly in an open and decentralized system, but instead of accepting a tradeoff they decided they wanted all their desired features and threw away the “decentralized” part…
I’m really curious about this - why is it not possible in a decentralized system? I know there have been past attempts around web of trust. I’ve always wondered why something couldn’t be built using blockchain to store public keys. Key rotation could be performed by signing a new key with the old key and updating the chain.
Am I missing something obvious that’s not currently possible? Are there good research papers in this area I should read?
You don’t need a blockchain to store a bunch of self-signed public keys. PKI has been doing that for ages via certificates.
OTOH, if you want globally-consistent (and globally-readable), unforgeable metadata associated with those keys you need some arbiter that decides who wins in case of conflicts, what followers/“following” graph edges exist, etc.
Nostr actually uses existing PKI (via HTTPS + TLS) to “verify” accounts that claim association with an existing public domain. Everything else is…well, not even “eventually consistent” so much as “can look kinda consistent if you check a lot of relays and don’t sweat the details.”
It’s possible, but you need some kind of distributed consensus, which in practice looks like a blockchain. ENS is one implementation on Ethereum. You also need some mechanism to prevent one person from grabbing every name (if you assume sybil attacks are possible, which they will be on almost any decentralized system). The most common one is to charge money, which is not really ideal for a social network (you want a very small barrier to entry)
You also need some mechanism to prevent one person from grabbing every name
An interesting take on this is done by the SimpleX network: it employs no public identifiers. The SimpleX Chat protocol builds on top and continues this trend. You can build a name service on top, but the takeaway I make is that maybe we don’t need name services as often as we think.
The assertion of Zooko’s Triangle is that you can’t have identities that are simultaneously human-meaningful, globally unique and secure/decentralized. You can only pick two properties. DNS isn’t secure (you have to trust registries like ICANN.) Public keys aren’t human-meaningful. Usernames aren’t unique because different people can be “snej” on different systems.
The best compromise is what are known as Petnames, which are locally-assigned meaningful names given to public keys.
That’s an extreme description. I know it’s tagged as a rant, but still…
The whole bit about the protocol may not be how the author would like it to happen, but practically it makes sense to me. You could start from full openness and design by committee, or the other way like bluesky did - establish their own initial network and client in private and start letting people in at a slow pace. This way they can react quickly without having to break the network multiple times as they learn new things about scaling.
The BGS availability also sounds like a practical description. Whether you plan for it or not, the node sizes will most likely follow similar distribution to all the other distributed systems. For git there’s GH, GL, and the rest. For mastodon there’s a couple huge instances and the rest. For email there’s Google, MS and the rest.
Which means there’s an 80% chance they’re a bitcoin bro. I looked into Nostr. The tech is very cool, and I think could be practical as a social platform with a loooot of work. However pretty much everyone on there is a cryptobro or a spambot. Cryptocurrency is so far ingrained into that community, I fully expect it to be the reason it ultimately fails.
The protocol looks simple, aside from the cryptography parts. Their
affiliation with bitcoin obviously influenced their choices here. They
use SECP256K1 keys and Schnorr signatures.
A friend of mine was asking me about nostr last week, so I took a harder
look at it. As I was telling him last night, I have little inclination
to build anything using that protocol, because of (as I phrased it) the
“weird-assed obscure bitcoin tech”. I’d hope that someone starting a
project using cryptography in the 2020s would go for something that
could be implemented with, say, libsodium.
If there is one thing the crypto (as in stonks) sphere has contributed, it is the popularisation of zk crypto (as in cryptography). Admittedly, no zk crypto (as in stonks) has any practical value, they are purely research-quality POCs funded by speculation by the latest lottery winners.
I’ve worked on a zk-VM. One really valuable, future application of that is: verifiable compilation: give someone an executable binary, and a cryptographic proof that it was compiled with the source code in a git report with a certain HEAD. Beats just publishing the hash digest on the same website that hosts the binary.
Especially, the popularisation of “non-interactive” zk proof systems is interesting because they can be useful without the widespread adoption of some interactive network protocol. (Depending on critical mass to attain critical mass is an expensive strategy.)
Bitcoin bros are exactly the sort of people who care about decentralization and censorship-resistance in the realm of money (or else they’d be doing something else). Those are exactly the sort of people I want designing and using and promoting social media platforms.
The “excuse” is they look nice. I like them and people generally like or don’t mind them. They are a good place to put auxillary controls on restricted screen space. Nobody’s losing notable performance to hamburger menus.
I saw a completely fine, HTML + CSS hamburger menu contained within the nav element, on the front page just the other day - what’s inaccessible about that?
And I’m not sure what you mean by “adding them in HTML”, yes we’re talking about HTML attributes, but you don’t necessarily want to re-generate the whole HTML on the backed just to add one (1) attribute to a tag.
I see. Like I said higher in the thread, the way I solved simple one level menus is by using <details> with <summary> which I hope don’t need this attribute as they should implement that natively. (But I have to admit that there’s no indication in the docs if my assumption is right.)
Nobody’s losing notable performance to hamburger menus.
I saw […]
Not to nitpick, but the precise point is that they are hard to navigate for vision impaired people. It’s a spectrum and can be hard to understand when you take your vision for granted.
I’m nowhere near legally blind, but I do have vision impairment, and sometimes I just can’t see the hamburger menu. At other times I can’t click them properly because their reason for existing is to fit the visual layout, not to be clicked. (Too close to other clickable things with my fat fingers.)
On desktop I navigate at 200% text size, and often hit the “mobile version” of pages where the hamburger menu was not properly tested. They often don’t work because they were approved based on their mere presence. So I dislike them not just because they’re often hard to press, but also because they’re a second-class citizen: covering many items that were not important enough to highlight, but not unimportant enough to discard. A true token of design by committee accident.
They aren’t great for people with conventionally good vision either. My doctor says my vision is perfectly fine but I have a short of mental blindness for hamburger menus. I will look all around a website for navigation clues and just not see the hamburger icon. Sometimes that is because the designer used really low contrast but mostly it is because I have a specific idea of what I want to find (e.g. “investor relations” and doesn’t look for a generic “more stuff hidden here” signal.
I’m travelling back from China.
In transit, I’ll be toying with the git2 crate in Rust, trying to propagate the experimental sha256 feature flag from libgit2. The stacking of build systems here is a bit messy, and it seems like a bit of upstream untangling to do it right.
From the rant:
I’m really curious about this - why is it not possible in a decentralized system? I know there have been past attempts around web of trust. I’ve always wondered why something couldn’t be built using blockchain to store public keys. Key rotation could be performed by signing a new key with the old key and updating the chain.
Am I missing something obvious that’s not currently possible? Are there good research papers in this area I should read?
It’s well-trodden folklore; I’d start with Zooko’s triangle. Several forms of the triangle can be formalized, depending on the context.
You don’t need a blockchain to store a bunch of self-signed public keys. PKI has been doing that for ages via certificates.
OTOH, if you want globally-consistent (and globally-readable), unforgeable metadata associated with those keys you need some arbiter that decides who wins in case of conflicts, what followers/“following” graph edges exist, etc.
Nostr actually uses existing PKI (via HTTPS + TLS) to “verify” accounts that claim association with an existing public domain. Everything else is…well, not even “eventually consistent” so much as “can look kinda consistent if you check a lot of relays and don’t sweat the details.”
It’s possible, but you need some kind of distributed consensus, which in practice looks like a blockchain. ENS is one implementation on Ethereum. You also need some mechanism to prevent one person from grabbing every name (if you assume sybil attacks are possible, which they will be on almost any decentralized system). The most common one is to charge money, which is not really ideal for a social network (you want a very small barrier to entry)
An interesting take on this is done by the SimpleX network: it employs no public identifiers. The SimpleX Chat protocol builds on top and continues this trend. You can build a name service on top, but the takeaway I make is that maybe we don’t need name services as often as we think.
The assertion of Zooko’s Triangle is that you can’t have identities that are simultaneously human-meaningful, globally unique and secure/decentralized. You can only pick two properties. DNS isn’t secure (you have to trust registries like ICANN.) Public keys aren’t human-meaningful. Usernames aren’t unique because different people can be “snej” on different systems.
The best compromise is what are known as Petnames, which are locally-assigned meaningful names given to public keys.
Zooko’s Triangle describes the properties human-meaningful, secure, and decentralized. DNS is secure, not decentralized.
Oops, thanks for the correction. I was working from memory.
That’s an extreme description. I know it’s tagged as a rant, but still…
The whole bit about the protocol may not be how the author would like it to happen, but practically it makes sense to me. You could start from full openness and design by committee, or the other way like bluesky did - establish their own initial network and client in private and start letting people in at a slow pace. This way they can react quickly without having to break the network multiple times as they learn new things about scaling.
The BGS availability also sounds like a practical description. Whether you plan for it or not, the node sizes will most likely follow similar distribution to all the other distributed systems. For git there’s GH, GL, and the rest. For mastodon there’s a couple huge instances and the rest. For email there’s Google, MS and the rest.
Author is apparently involved with Nostr[1], which competes in a similar space as Bluesky.
[1] previously, on Lobste.rs:
Which means there’s an 80% chance they’re a bitcoin bro. I looked into Nostr. The tech is very cool, and I think could be practical as a social platform with a loooot of work. However pretty much everyone on there is a cryptobro or a spambot. Cryptocurrency is so far ingrained into that community, I fully expect it to be the reason it ultimately fails.
Also on that blog: Bitcoin is a gift from God that will bring the end of all inflation, all its other characteristics are secondary.
Good guess.
The protocol looks simple, aside from the cryptography parts. Their affiliation with bitcoin obviously influenced their choices here. They use SECP256K1 keys and Schnorr signatures.
A friend of mine was asking me about nostr last week, so I took a harder look at it. As I was telling him last night, I have little inclination to build anything using that protocol, because of (as I phrased it) the “weird-assed obscure bitcoin tech”. I’d hope that someone starting a project using cryptography in the 2020s would go for something that could be implemented with, say, libsodium.
If there is one thing the crypto (as in stonks) sphere has contributed, it is the popularisation of zk crypto (as in cryptography). Admittedly, no zk crypto (as in stonks) has any practical value, they are purely research-quality POCs funded by speculation by the latest lottery winners.
I’ve worked on a zk-VM. One really valuable, future application of that is: verifiable compilation: give someone an executable binary, and a cryptographic proof that it was compiled with the source code in a git report with a certain HEAD. Beats just publishing the hash digest on the same website that hosts the binary.
Especially, the popularisation of “non-interactive” zk proof systems is interesting because they can be useful without the widespread adoption of some interactive network protocol. (Depending on critical mass to attain critical mass is an expensive strategy.)
That’s certainly what turned me off to nostr HARD.
The main question is, do you need some crypto token to operate the protocol, or is the protocol just preferred among crypto bros?
As far as privacy-preserving protocols, I don’t understand why we don’t see more that mask as regular https traffic.
Bitcoin bros are exactly the sort of people who care about decentralization and censorship-resistance in the realm of money (or else they’d be doing something else). Those are exactly the sort of people I want designing and using and promoting social media platforms.
Idunno I’m pretty sure they’re about grifting and denying their accelerating catastrophic climate change.
The “excuse” is they look nice. I like them and people generally like or don’t mind them. They are a good place to put auxillary controls on restricted screen space. Nobody’s losing notable performance to hamburger menus.
I saw a completely fine, HTML + CSS hamburger menu contained within the nav element, on the front page just the other day - what’s inaccessible about that?
Actually CSS is not really the best way to make accessible interactivity. You need a bit of JS to add aria attributes when your menu opens. :)
Which attributes? And is it possible that adding them in HTML is an option?
This one: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-expanded
And I’m not sure what you mean by “adding them in HTML”, yes we’re talking about HTML attributes, but you don’t necessarily want to re-generate the whole HTML on the backed just to add one (1) attribute to a tag.
I see. Like I said higher in the thread, the way I solved simple one level menus is by using
<details>with<summary>which I hope don’t need this attribute as they should implement that natively. (But I have to admit that there’s no indication in the docs if my assumption is right.)Reading from the following page, I believe we cannot fully rely on screen reader support in a cross-platform way for
summary: https://a11ysupport.io/tech/html/summary_elementGood resource, thanx a lot.
This artickle posted here previously has some more links regarding a11y hamber menus.
IIRC some of the “css only” versions are simply invisible or hard to navigate via screen readers.
Not to nitpick, but the precise point is that they are hard to navigate for vision impaired people. It’s a spectrum and can be hard to understand when you take your vision for granted.
I’m nowhere near legally blind, but I do have vision impairment, and sometimes I just can’t see the hamburger menu. At other times I can’t click them properly because their reason for existing is to fit the visual layout, not to be clicked. (Too close to other clickable things with my fat fingers.)
On desktop I navigate at 200% text size, and often hit the “mobile version” of pages where the hamburger menu was not properly tested. They often don’t work because they were approved based on their mere presence. So I dislike them not just because they’re often hard to press, but also because they’re a second-class citizen: covering many items that were not important enough to highlight, but not unimportant enough to discard. A true token of design by committee accident.
They aren’t great for people with conventionally good vision either. My doctor says my vision is perfectly fine but I have a short of mental blindness for hamburger menus. I will look all around a website for navigation clues and just not see the hamburger icon. Sometimes that is because the designer used really low contrast but mostly it is because I have a specific idea of what I want to find (e.g. “investor relations” and doesn’t look for a generic “more stuff hidden here” signal.