Maybe time isnt required, but order (sequence).
Nostr signing to outbox could include a sequence kv (tag, number) - e.g. public:665, dm: 34323. You declare in outbox who can fetch your current sequences counts.
Would let clients find dropped posts, and let users know what they have signed.
Sadly AIs are trained to appease your opinion. You can try it out: disagree three times with an AI and it will end up softly agreeing with your resolution....
By being your friend they become trusted (Maximum engagement). The truth needs reasoning, which needs rationalism. But we live in a fake data world of empiricism.
You're just reading the wrong economics.
They'll snatch those machines at first opportunity!
Sounds fantastic!
So inspiring. Kind regards.
The protocol stack already does this when the mints are inter-connected over Lightning.
The only thing needed is a special "audit transaction" on lightning that confirms lightning funds available to send as the mint treasury.
Meshtastic for the win!
A header event of a Publish on multicast would stop the channel being burdened with data, then subscribers can choose to filter or fetch at their own convenience.
A header would allow subscribers some interesting use cases…
- local mode: prioritise local (subnet) content, defer external
- p2p mode: allow those with header to fetch from your notedeck’s sent queue (as a pseudo relay). Stealth mode, or a data sync if you hand off to a tcp port.
Be great for mesh networks.
Many people would have seen nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s 's note about Notedeck supporting multicast relays. As a network engineer, I found this interesting, but I'm sure there were people wondering what multicast is or how it works so I thought I'd have a go at writing an educational note to try to explain the operation of multicast as simply as possible. It is a complex topic so I’ve limited it to a very simple network and IPv4 only.
I've created a diagram that shows the three types of traffic found on a network - unicast, broadcast and multicast. Most connections are unicast with one host sending packets directly addressed to another host that receives them. This is how most communication occurs across the Internet.
Broadcast packets are sent to a special broadcast address (the last IP address in subnet, in this case 192.168.1.255) and are flooded to every host within the LAN. Broadcast traffic is used for things like discovery of devices and for DHCP when a device is first obtaining an IP address. Broadcast traffic is "noisy" as the packets are sent to every device, even if the device does not need the traffic.
Multicast is a way for one device to send packers to many other "interested" devices at the same time. The advantages of this is that the packets only need to be transmitted by the sender once and those packets are then only forwarded by the switch only to devices that want to see the traffic. Common uses for multicast are CCTV systems, IPTV, and IP telephony music on hold systems. It is also used by Apple and other devices for mDNS device and service discovery.
Multicast traffic is identified by a multicast group IP address in the range 224.0.0.0-239.255.255.255 (239.255.100.100 in my diagram). Each host that wants to receive the multicast traffic will listen for packets on this address. Internet Group Management Protocol (IGMP) is used to co-ordinate group membership. In order to join a multicast group, a request is sent by the host to an "IGMP Querier". The IGMP querier may be a router or some switches have this functionality. The switch listens to the IGMP messages (IGMP snooping) to build up a table of which switch ports has devices that want to see traffic to a multicast group address and the multicast packets are then sent out those ports.
There are some considerations when using multicast. Many cheap, unmanaged, switches don't support IGMP so will treat multicast traffic as broadcast. Packets still reach the destination but the benefit is lost as they are flooded out all ports. There can also be issues with multicast on some WiFi networks. Finally, because multicast is 1-to-many, it needs to use UDP rather than TCP. This is relevant for the Nostr use case as it requires a different protocol to websockets that is used for connections between clients and relays. 
Well done.
So does this mean notedeck is now also running with a upd port and doing IGMP lists?
Notedeck is starting to look like an Erlang VM…
Click away!
They are trying desperately to maintain their artificial peg to the USD to avoid Trumps tarrifs.
My First 3 Thoughts About Using Nostr.
1. The feed here feels clean, less like a firehose of nonsense, and more like an experience. Social media fatigue has been my biggest hurdle to trying something new. Between 𝕏, Facebook, and Instagram, keeping up has been exhausting as a solopreneur. But this? It’s like revisiting “Old ways, new days.” Honestly, it’s pretty damn cool to see a space that feels this refreshing. I’m getting the late1990s AOL WaReZ room feels.
2. Let’s face it…the way social media monetizes engagement is a dumpster fire, as it rewards spammy behavior, divisive posts, and clickbait nonsense. Here, the idea of people directly rewarding people feels…right. It aligns incentives in a way that makes sense; over time, I think this will be what sets Nostr apart.
3. The overall vibe here? Optimistic. It’s refreshing not to wade through the black-pilled doomers dominating 𝕏 these days. Over there, it feels like the loudest voices are just shouting their opinions into the void—and honestly, I’m over it. Here, the conversations feel constructive. People want to contribute something meaningful instead of just making noise.
Massive thanks to nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m, nostr:npub1rtlqca8r6auyaw5n5h3l5422dm4sry5dzfee4696fqe8s6qgudks7djtfs, nostr:npub1s05p3ha7en49dv8429tkk07nnfa9pcwczkf5x5qrdraqshxdje9sq6eyhe, and nostr:npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx for staying on the gas about it. I should have listened to you guys much, much earlier ✊🏽
Good Morning. Welcome.
GM Nostr! 🌞
🎁 Announcing Keycast 🔑
A remote signing platform for teams.
https://share.cleanshot.com/y4XbqKpT
Remote signing (NIP-46) has always had a lot of promise. Apps like Amber, nsec.app, and others have made it possible to manage your nostr keys in a way that is safer than browser extensions or pasting your nsec around the internet.
BUT, none of them catered to teams. Groups like nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l and nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk and many many companies out there are just sharing the main account nsec between different people and using it in different apps. A recipe for disaster.
Keycast aims to finally fix this. It allows you to:
- Manage teams of nostr users
- Manage multiple keys that you want to give others access to
- Create authorizations for those keys that grant specific permissions that can be changed, revoked, etc.
- Create your own custom permissions
- Run the signing infrastructure without any extra work
And do it all in a self-sovereign way. Keycast is meant to be run on your server, by you. I think it's tremendously important that this sort of tool doesn't exist as a hosted service (which would basically be a huge key honeypot over time).
The app is both a management web app AND a backend process that manages sub-processes that listen for remote signing requests, check permissions, and sign events.
There is a basic docker setup to start, but my goal is to have this easily deployable to StartOS, Umbrel, Podman, and others.
Code here: https://github.com/erskingardner/keycast
Bravo!
GM Nostr! 🌞
🎁 Announcing Keycast 🔑
A remote signing platform for teams.
https://share.cleanshot.com/y4XbqKpT
Remote signing (NIP-46) has always had a lot of promise. Apps like Amber, nsec.app, and others have made it possible to manage your nostr keys in a way that is safer than browser extensions or pasting your nsec around the internet.
BUT, none of them catered to teams. Groups like nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l and nostr:npub19mduaf5569jx9xz555jcx3v06mvktvtpu0zgk47n4lcpjsz43zzqhj6vzk and many many companies out there are just sharing the main account nsec between different people and using it in different apps. A recipe for disaster.
Keycast aims to finally fix this. It allows you to:
- Manage teams of nostr users
- Manage multiple keys that you want to give others access to
- Create authorizations for those keys that grant specific permissions that can be changed, revoked, etc.
- Create your own custom permissions
- Run the signing infrastructure without any extra work
And do it all in a self-sovereign way. Keycast is meant to be run on your server, by you. I think it's tremendously important that this sort of tool doesn't exist as a hosted service (which would basically be a huge key honeypot over time).
The app is both a management web app AND a backend process that manages sub-processes that listen for remote signing requests, check permissions, and sign events.
There is a basic docker setup to start, but my goal is to have this easily deployable to StartOS, Umbrel, Podman, and others.
Code here: https://github.com/erskingardner/keycast
What happens when your memory page faults? And how many writes?
Technology decisions matter: They can have profound divergence the more water that traverses under the bridge....