Last Notes
Sidecar now shows both in notifications, and replies in the corresponding kind to each, so whichever path of pain the majority of clients choose, we can be ready.
@nprofile…vhl6 does gitworkshop.dev having namecoin nip-05 resolution count as the 2nd client? also, *chef's kiss* https://github.com/nostr-protocol/nips/pull/2472#issuecomment-5743856928
broadcast is exactly how bitcoin and cryptocurrency networks propagate the very transactions you are already depending on. broadcast can be made more efficient, there is technique called "reliable broadcast"
reliable broadcast
**Reliable broadcast** is a distributed computing primitive that ensures all operational nodes in a network receive and process the same message exactly once, even if connections are faulty or some nodes fail. Unlike simple best-effort broadcast, it guarantees **validity** (messages from correct senders are delivered), **no duplication** (each message is delivered once), **no creation** (messages are not fabricated), and **agreement** (if one correct node delivers a message, all correct nodes do).
Key variations include:
* **Atomic broadcast**: Adds a **total order** property, ensuring all nodes deliver messages in the same sequence, which is critical for replicated state machines.
* **Byzantine reliable broadcast**: Handles **Byzantine failures** (malicious or arbitrarily behaving nodes), requiring protocols like **Bracha’s algorithm** to tolerate up to $f < n/3$ faulty nodes in a system of size $n$.
* **Causal broadcast**: Ensures message delivery respects **causal ordering**, meaning a message is only delivered after all its causal predecessors have been delivered.
Recent research focuses on optimizing **communication complexity** and **round complexity**, with new protocols achieving optimal performance using hash functions or probabilistic methods to reduce overhead in large-scale systems.
---
i'm happy to advise you on distributed systems theory but you have to actually believe i know what i'm talking about or i'm wasting my time.
as for revocable keys, i have several opinions about nostr that i will be addressing when i finally get to building a protocol:
1. the message layer should use the same standard as email - first column sentinels are the cheapest way to segment message formats, it is trivial to create tree structured notations too
2. nostr's cryptography is very wrong. identity should be separated from encryption. in PGP, you have got 2 keys by standard default in your keychain for each identity, one for authentication (identity) and one for encryption. this ensures that if the encryption key is cracked, the authentication key is not. encryption exposes more vectors for deriving the secret than the far less frequent signatures (nostr event signatures are an authentication key use case).
3. what i would do with it is use a seed, a bip-39 seed would give you the actual secret. the first derived key path for authentication would be the "master" key as in your scheme. then you would have a chain of secondaries that are derived on the path. HD keys if you break one, you can break anything that is rooted to it. this does not include other paths, they are isolated by hashes. with the scheme i have in mind, you can even revoke the master key that signs revocations, by having a master key path, then an auth key path, and then you can do all kinds of neat things with derivation trees for encryption. yes, the only thing this doesn't cover is leaking the keychain seed. but since that is pretty much a physical/hardware attack vector we can ignore it, that's just the basics. leaking and loss are both bad. a 24 word seed would ensure you could keep a copy on paper, using a password encryption on that key, which would provide you with a backup mechanism that doesn't expose you to physical attack.
and 4. i have thought for a long time about how to make nostr protocol do broadcasting properly. for a start, it should be simple enough to point out that all users have relay lists, and a relay could propagate any event sent to it based on this list, meaning you can use multiple relays (or even select one at a time randomly) but actually only have to post to one of them, get a send ack, and know that not only has all of your notes been sent to all your other relays, it can go further where the relay is searching the tags of events and for every p tag it searches for a cached copy of the user's relay list, and propagates it there too. and you can go further, mute lists can be used by relays along with follow lists to identify which users should be able to post events to a given relay in outbox model, without being subscribers, and as well, which users should not be able to post to a relay, where the event tags a user who has muted them.
there is SOOOO many things i could fix about these systems it boggles my mind that everyone stops at the point where i say "i don't like adam back or samson mow or odell" and think that - and these are things i have been saying for years btw, which are now totally vindicated, i smelt those rats years ago, their actions reek of sophisticated malice. nope, we don't want to have this guy building our systems architecture because he doesn't like some popular guy.
what can i say. it's everyone else's loss. you don't have to agree with me just because of who i don't like, to understand that i have in depth, 20+ years of experience in doing game theory, systems architecture, protocol design and security. but you are too salty. ok, whatever. glhf. pls stop responding to my messages, and i promise i won't reply to yours any further either.
If "convergence delay" is meant to refer to a delay that occurs before *relays* agree on the same set of revocations, then that term carries a presupposition that relays *will* at some point converge. As far as I can see, there isn't any particularly strong reason to think that they will ever converge.
(I'm not sure what "DST" is.)
This is basically where I am on it. I do care. I just have a career outside Nostr and don't have the time to fuck around with every new thing that's released somewhere (if I even see it). Things are usually poorly built and rarely work well enough to justify paying attention. Could be a self-fulfilling loop, but that's where I am.
I think the concept is awesome if it can actually be done securely and simply enough that I don't blow my own head off in the process.
Do you mind if I pull some stuff from there? I like the vercel stuff.
Started using @nprofile…wywf . It has everything but half baked like @nprofile…hxgr
But overall usable enough
Oh, If the relay is empty but stays connected it still counts correctly. The problem was that relays were killing the connection and our counter didn't change.
Let's go @nprofile…nvfv @nprofile…y0fu , time for the return 😘
Drafts sync with Amethyst @nprofile…vhl6 🤙
i made a bunch of changes so i've already diverged a bit. for example, i don't use claude much so i moved the skills into a .agents folder. deployment is done using a skill and is not very generalized. i mostly use vercel so vercel logic is hardcoded in the skill.
https://github.com/SamSamskies/the-nostr-observer/tree/main/.agents/skills/observer-pages
Did you had to modify the code to deploy this? We accept PRs :)
new edition published every morning after i make some coffee 🚀
Daily version of The Nostr Observer computed from @nprofile…rlat's point of view. 🚀
https://thenostrobserver.vercel.app
I am confused. What is this about?
@nprofile…vhl6
Hey, does Amethyst use libheif?
#nevent1q…62le
@npub1gcx…nj5z implemented most of the magic that generates the paper. i've been using gemini flash 3.8 as the editor and it's been doing a good job. tried a bunch of other models and so far i like that model the best for putting together the paper.
watching it now.
For the record:
@npub1yxd…3ylt
@nprofile…nj27 @nprofile…2szn @nprofile…vhl6 @nprofile…wcv8
nostr got mentioned in this recent ted talk 🤯
http://go.ted.com/leopoldolopez26
more reliable? unreliable? relia-bro?
Lots ofmreliabro replicas
I think it's difficult to do without a blockchain.
@nprofile…vhl6 @nprofile…afdc @nprofile…wx58 I created a test page for a possible key rotation system on Nostr. However, it doesn't use that NIP draft implementing a single Ethereum contract. https://nostr-key-rotation.shakespeare.wtf/
Brick poo! 🪨😁😁😁
Wombat 1 x Humans 0
Humans cannot do that😁😄
#nevent1q…eup6
Humans cannot do this😁😄
#nevent1q…eup6
A feature recently introduced is to limit the features you are exposed to. You can now limit the left dock to only the features you use and hide the rest... :amethyst:
Podcasts in @nprofile…wywf ? 👀
Any chances we get OPML import support?
https://npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z.blossom.band/d385bffd063f2cd85586a1a1dc6942606ccf1bcc43c754c6e11df299487ede2c.jpg
@nprofile…vhl6 please sir, people like assange need it
#nevent1q…7lr4
Круто, когда приложуха постоянно развивается
#nevent1q…7259
All good, would you say that the UI in primal Android is better than the UI on Wisp?
The number of features added. I also found that the UI / layout of Primal is more intuitive for me.
My leaving is not an indictment on your work. Amethyst is a great app and for many users the number of features may be a big plus. Just wasn't ideal for me over time.
@nprofile…5xqv 总结紫水晶1.16有什么新变化
#nevent1q…ughm
What made you leave amethyst? :)
#Amethyst v1.16.0: My Fitness, BOLT12 Payments, and a Leaner Core
Highlights:
- Adds **My Fitness**, a dashboard over everything you have trained.
- Moves **BOLT12 offers** into the profile payment rail, and zaps over BOLT11
when a wallet refuses one.
- Opens the **zapped note** from wallet history.
- Fixes **Blossom uploads**, broken on most servers since 1.15.0.
- Takes **~40 MB off every `amy` distribution**.
- Stops counting a relay that hung up as connected.
- Updates **Arti to 2.6.0** for two medium-severity fixes.
## New Features
### My Fitness
- Adds a training dashboard, reached from the drawer or a pinned bottom-bar slot.
- Builds it from both sources: Health Connect, and the kind 1301 workouts you
published. Neither is required.
- Summarises four weeks: this week against last, weekly averages, a breakdown by
activity, best efforts, active days and a day streak.
- Shows distance, calories, steps, climb and heart rate only when a workout
carries them.
- Offers to share a workout only when it is not already published.
- Prefers the Health Connect copy when the same effort appears in both sources —
it carries the heart rate, steps and climb the published event drops.
- Filters the Workouts feed by **Mine** from the top nav.
- Reads workouts in the POWR dialect, which carry `start`/`end` and no `duration`.
### Payments
- Renders each BOLT12 offer as a chip in the profile payment rail. Offers were
already payable, but only through a small button in the profile header.
- Removes both header wallet buttons. The rail lists everything they reached.
- Shows the zap bolt to recipients who publish an offer and no lightning address.
The send path already paid them; the picker just never offered it.
- Falls back to a BOLT11 zap when a wallet refuses an offer and the recipient also
publishes a lightning address.
- Retries only refusals that mean nothing was attempted. A `PAYMENT_FAILED` can
still settle later, so retrying it could pay twice.
- Reports a timeout when a wallet never answers, instead of hanging the zap.
- Opens the zapped note when you tap a zap in wallet history.
## Performance
- Stops emptying the media connection pool on every client rebuild. Both HTTP
clients share one pool, so the proxy check misread every rebuild as a route
change.
- Drops pooled connections once per real Tor route change instead.
- Stops `debugState()` walking the whole cache on every backgrounding. Its nine
scans were built eagerly and then discarded unread.
- Signs one Blossom read-auth token per server, not one per racing caller.
## Improvements and Bug fixes
- Sends the Blossom authorization token as standard padded Base64 again. Deployed
servers reject 1.15.0's unpadded base64url, so roughly two uploads in three
failed.
- Points the Sovbit default Blossom server at `files.sovbit.host`.
- Answers a relay's WebSocket CLOSE frame, in both the shared and the Android
socket. Without it a closed socket looked connected for up to four minutes,
silently discarding everything sent.
- Counts connected relays from the pool's connected flow, which the pool now
clears itself whenever it drops a relay.
- Renders a GIF with no `imeta` as a loading placeholder. It used to collapse the
whole note to a gap in the feed until the fetch finished.
- Drains the event-sync outbox before closing the client. Events from the final
page were reported Done and never delivered.
- Fixes 34 bugs found auditing `commons` and `commonsUI`. Among them: AES-GCM
initialised with a spec every JDK rejects; an `Onion-Location` header from any
host re-pointing Tor traffic for 24 hours; a bundled insert wedged after one
exception; a URL validator backtracking exponentially per keystroke.
- Uses `https` in preview data and image-URL placeholders.
## Desktop
- Stops a silent account wipe on macOS. One Deny on the Keychain prompt rotated
the encryption key and orphaned every saved account.
- Consolidates the keychain into a single `vault-v1` item, so a cold boot prompts
once.
- Allows first-launch key bootstrap on Linux and Windows.
## Cli
- Ships ~40 MB lighter, now that `amy` no longer drags Compose UI and Skiko behind
`commons`.
- Fails fast when a buzz-agent wrapper cannot be made executable.
## Quartz
- Answers a duplicate `EVENT` with `OK true`, per NIP-01, and a superseded
replaceable the same way. Clients used to get raw SQLite text they could not
classify, and retried forever.
- Gives each socket adapter its own session, removing the pool's locking and
identity checks.
## Build & Documentation
- Updates Arti 2.3.0 → 2.6.0, the JNI crate to 0.22, the NDK to r30 and Rust to
1.98.1. Picks up TROVE-2026-24 and TROVE-2026-27, both reachable in normal use.
- Splits Compose UI out of `commons` into a new `commonsUI` module. 236 files
moved and no consumer import changed.
- Bumps LightCompressor-enhanced to 2.2.3.
- Drops the unused Guardian Project Maven repository.
- Runs relay-backed tests against geode instead of external relays.
- Clears the compiler, Android Lint and Gradle 10 deprecation warnings.
- Bumps `appCode` to 461.
## Contributors
- @nprofile…vhl6
- @nprofile…m3sx
- mstrofnone
## Translations
- Polish by @nprofile…8c53
- Hindi by @nprofile…z0lu
- Hungarian by @nprofile…ns2l
Today I learned something
#nevent1q…hjkk
Haha. It is shitting bricks. lol
Funny bug in @nprofile…wywf on Pixel 10 pro with GrapheneOS.
https://cdn.nostrcheck.me/e5c7fb93f7c3dcab987340fa92271b890d7c4a32002a52339be4ba892d62d276.mp4
Wombats take up to two weeks to digest their food, extracting nearly all the water and nutrients. This makes the waste extremely dry and firm
https://npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z.blossom.band/c5697855bea9d61d6c66e01c57b746f9b2fb4131aab04332624cb5b40bda127d.jpg
https://nostpic.com/media/5e5fc1434c928bcdcba6f801859d5238341093291980fd36e33b7416393d5a2c/3335b552594a1eb3be6300fd345df708fca6e6f7d32757e095491585733cdc7e.webp
#boobstr got bigger in size
Help record the Nostr Compass #40 podcast. Pick the intro or any section from this week's issue and leave a short voice note in Logbook whenever it suits you.
Issue: https://nostrcompass.org/en/newsletters/2026-09-16-newsletter/
Record: https://npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.nsite.lol/#/login
Participants: @npub130m…l29s @npub142g…xrj0 @npub15qy…yejr @npub17h9…3hpu @npub1937…haj6 @npub1dmm…mc87 @npub1gxd…5zfk @npub1hw6…65gr @npub1mar…r6m9 @npub1qu7…7p98 @npub1qwk…qfvl @npub1w4u…0jr5 @npub1xdh…eycm
https://npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z.blossom.band/a5ac07069cfc1c1bb127f4e80f3d2773b86e132e440ca387d7185d156ee1244e.png
GM! Thank you! 🙏 Shipping out today!
