Last Notes
The only question is whether we can find the solutions with the right tradeoffs before falling back to politics completely.
Bitcoin brought adaptive proof of work based money, nostr gives us the simplest primitives for sovereign identity and independently verifiable data.
These protocols let us design freedom oriented, natural, human-scale systems.
Hard coordinaton problems in digital space should always fall back to a solution in meatspace, there will not be a time where we completely let machines decide everything for us I hope.
#nevent1q…n5z7
By the way you can create a sign in with google experience today with frost fiatjaf had a demo I think.
You can run a bunker signer for your mom, or later when ppl have much at stake there will be professional co-signing services.
The problem with append only state is that remember:
From the other partie's perspective who only sees your signed event, delegated signing is key rotation.
For your idea to work you must (as you mention) introduce an append only tracker of your key states.
This is the exact point where you introduce a strict ordering burden on Nostr verification since now everyone must take a roundtrip:
"Do I know this key? This could be xyz's subkey/delegated key so let's look up the original to verify the real identity" and this must be done each event.
And if you leak the subkey it's even worse, now you have to introduce even more extra roundtrips and edge cases where a client must look up the history of revocations with each and every event verification process.
So a delegation process producing a different signature will not work practically in my opinion.
The delegated signing process must produce the same signature as the original key.
This is what FROST solves. Your nsec is sharded and you define in the key ceremony what kind of quorum you will use.
Let's say 2/3. Now you keep one on a server, one on your phone and one just in cold storage (for now).
If the server or the phone is compromised you get the 3rd shard and never trust the compromised one again. These tools exist already you can experiment with them.
The burden / complexity is now on you instead of the whole network to make sure that the compromised shard is being handled (you cannot revoke it) but realistically you can drop it, and use the other 2 or even add further keys to the quorum, making it practically 2 of 4 etc.
Note that adapter signatures could be used differently but Frost has additional benefits.
AtProto (Bluesky) solves this by introducing a trusted so called PLC server that tracks key rotations. You cannot practically run your own equivalent because that's hardcoded into each client solving the consistency / roundtrip problem I described above. It's that theoretical thing that doesn't work in practice, and they acknowledge that.
All in all UX can go a long way so a co-signer FROST setup can be quite convenient to use with the right tooling, and services.
And if all breaks we always fall back to meatspace, there will never be a perfect solution, that's alright I think. Bitcoin can be hardforked even with overwhelming consensus.
Note that key rotation is essentially just that:
You want the whole world to overwhelmingly accept that the state of your identity changed. That is an oracle problem and Bitcoin handles it the same way:
Leaves it open.
That's why altcoins exist.
You fork an identity that's your alt identity. I don't have to accept but I cannot exclude others to accept it and enforce it practically.
The difference is that rotation of your identity will not affects global trade so it will be alright.
This is cool!
Can agents use Opal locally without the relay roundtrips?
I think the problems you pointed to are real so they already manifested. Perhaps not enough ppl realize yet.
I also say that a pragmatic optimism is warranted though.
So in a way yes, I am saying most problems will be solved. Not sure about the timeline and want to accelerate the solutions to problems I see more pressing, that's my part.
Yes the narrative has been misleading it's not ideal.
However with more overall bitcoin adoption, including adjacent tech, we will hit obvious walls if what you say is true:
- Big LN nodes failing / hacked due to too much complexity
- Adverse fee environment destroying LN UX for the nth time
- Backlashes from 99% kyc custodial wallet usage
- Just sheer fatigue and churn of developers and non-custodial users alike
If these will play out increasingly, the issues become obvious and the problems need to be addressed. To some extent Spark, Ark and even #Cashu came about for exactly these reasons.
I know it's very hard to be among the first adopters because we tend to be impatient for the tech to succeed (like nostr) and when we face the chasm to cross it can burn us out quickly.
Endurance and timing are most relevant in this situation.
You look at Lightning and especially how hard it is to run a node securely and economically and one can realize this is made for industrial grade batched bitcoin transactions.
But it does scale bitcoin in a way, it allows for institutions to cheaply send and receive and this benefit trickles down the value chain: A cheap LSP e.g.
It's like a checking account for tenth the cost of what it is today, and stronger exit guarantees.
However, to truly scale bitcoin to microtransactions, we might not be able to avoid custodians.
Hope ark and spark help this situation but I don't see them solving this problem as cleanly as people would like
So I guess you considered #Frost if you have been thinking about this for a long time but you haven't mentioned it. Why?
Key rotation on the nsec level will hardly be a thing unless there's some cryptographic breakthrough because it would centralize the protocol, see PLC in atprotocol and such.
You basically must centralize key lineage tracking to a trusted party but that just doesn't go well in a distributed system.
Frost shard-based signing UX can be very stable and fairly revocable, it's just not yet spread so much.
Social rotation is the other way, it's been talked about many times. It is a viable alternative in a network like nostr, especially if communities get more popular.
The reason why there's not too much anxiety over this is just the fact that there's not yet enough demand I think for nostr in general.
We're building things out and if there's real pressure in the future from economically relevant users accruing, at some point it's gonna be figured out.
Massive scale corrupts massively
> I think it is important to say specifically how pacing will allow us to make the AI development process safer.
---
Specifically, I hope to get hold of smart enough unrestricted AI hosted safely in my apartment. That constitutes safety for me.
https://darioamodei.com/post/we-must-pace-the-frontier
Didn't know so much wokism is left in Linux land:
https://stopomarchy.neocities.org/
It's only time that can show the true nature and benefits of Nostr.
Waiting for the masses is futile, we must go step by step, first a focused cypherpunk group then work our ways towards a broader audience.
That is why niche apps are more justified currently than anything else
My first idea would be around agent-identity, Omarchy people appreciate AI and Nostr can is a good fit here
#nevent1q…96ty
Dev story time: How SatShoot ended up using partial #outbox model:
Using NIP65 relay lists to decentralize discovery looks like a fantastic concept at first...
And then you realize that most things taken to extremes ends up in the complete opposite way you intended.
This is true for the outbox model. You want decentralization. Maybe you convinced a lot of people to publish outbox relay lists (BIG maybe), so far so good. Still, you ended up with an app that connects to hundreds of relays **and keeps those connections alive**.
Problems:
- app uses a lot of data
- app will make your phone run flat in no time
- app likely gets heavily resource constrained by the OS when user switches away, relay conns are killed
- app code has tremendous added complexity (perhaps the worst of all!)
So what this effectively ends up doing is:
- only native apps will be able to handle this kind of load, maybe only desktop apps
- only people with close-to unlimited data plans will be able to use your app
- very few people will be able to understand your code, if any (including you)
So you ended up introducing all these centralizing dynamics, while users don't even understand or appreciate why you did it. And of course it all still relies on purplepages to fetch the initial lists, right? ;)
I had a better idea (communities are even better but until they come online this is my approach):
1. Use explicit relays by default, let normal users set explicit relays, and superusers set outbox too
2. Publishing is simple since it is targeted: you just publish to explicit relays + outbox (or inbox of target if it's a reaction to sth or mentioning someone)
3. You calculate optimal relays and fetch all relevant events ONE time, on a user-triggered "Decentralized Discovery". This should explain what's happening and why it's super cool.
4. Show the progress and at the end, add top relays to the pool for that session
5. User thinks "This is cool, I'm doing the Decentralized Discovery, Nostr Rocks!" and you did not have to keep all those connections and constantly keep score and all that. Just do it once.
This is now implemented in SatShoot:
https://v.nostr.build/8bZAOIjVjsCf41pm.mp4
Opinions?