Damus
Open in Damus

Recent Notes

semisol · 2w
AD is plaintext, yes. The point of the AD is that it is implied from event context, so kind is just the kind, and scope would be say the d tag or community ID or something else that is already plaintext.
John Carvalho · 2w
Pretending you don't need scaled servers is not the same as not actually needing them.
 arthurfranca profile picture
arthurfranca @arthurfranca
For Nostr, atleast, it depends on what it wants to be. I myself don't understand what people expect from Nostr relays.

I would like Nostr to be free public relays that hold events for just 2 to 3 days, unless you pay them or are an influncer that brings traffic that could be of use for the operator somehow. <- This doesn't need scaled servers.

Though it looks like most of the current users and apps expect big relays and blossom servers to store events and media for free forever, which is an illusion.
1❤️1
John Carvalho · 2w
What you want is incompatible with reality, as you have already noted ;)
John Carvalho · 2w
Why do you think there are any limits to any of this stuff? It is just a pile of various unenforceable best practices that people converge on. Look into our semantic social graph and nexus indexer. ...
 arthurfranca profile picture
arthurfranca @arthurfranca
I see, there's a need for an indexer to aggregate content from homeservers and then make endpoints available for fetching filtered data, like these: https://nexus.pubky.app/swagger-ui/.

There are pros and cons to doing it this way. Offering a reference implementation full of features from the start has its advantages. Requiring a big server is one disadvantage in comparison to non-indexer Nostr relays.
1✅️1
John Carvalho · 2w
Pretending you don't need scaled servers is not the same as not actually needing them.
fiatjaf · 2w
Stuff you publish to your homeserver doesn't have to be signed, so your key doesn't have to be hot. If one wants to verify if you really said something they have to connect to your homeserver and ask...
 arthurfranca profile picture
arthurfranca @arthurfranca
And by not imposing any shape to the data, it most likely means there's no API for searching data by some specific content field (as we have with one-letter event tags).

I think there's just fetching by path (like folders) and anything beyond that would have to be made custom by homeservers that care (similar to NIP-50 extensions). This aspect seems limiting.
1🤔1
John Carvalho · 2w
Why do you think there are any limits to any of this stuff? It is just a pile of various unenforceable best practices that people converge on. Look into our semantic social graph and nexus indexer. It's a freeform open graph for coordination.
arthurfranca profile picture
Nostr relays are means to broadcasting messages that live enough time for interested peers to fetch'em when they come online. Expecting no more than 2-3 days of event retention from free public relays is a safe bet.

Is this why Signal (not MLS, yes) requires millions of dollars a year for a "beefy server"?

1❤️2
τέχνη · 3w
Nostr is literally a “dead drop” system. You’re leaving notes for friends to pick up at random locations
franzap · 4w
Yeah, this makes more sense
arthurfranca profile picture
Why do some people want key rotation on Nostr? That's bad.

Like, you DM me about secret stuff, then I rotate to a new key, then I reveal my old key for anyone to decrypt and read those messages with proof that you wrote them.

Am I missing something?
4
Technical Debt · 5w
Yeah, praying that your nsec never leaks is the sane thing to do 🙏
frphank · 5w
You use rotating keys for signing, not for encryption. For encryption you can look at something like the double ratchet protocol. You basically create ephemeral keys that you throw away instead of revealing them.
inkan · 4w
I'm not sure I'm following. Why would key rotation require you to reveal an old key that wasn't revealed before? I'd think of key rotation as the user announcing that, from now on, they won't use key pair X for signing events but will instead use key pair Y. In doing so, no old keys are revealed to...
arthurfranca · 4w
thx for the different points of view. they have helped me improve a draft chat spec I wrote some time ago. I want to position it between nip-17 and marmot in terms of ease of implementation, functionality and privacy.
Jumble · 9w
https://jumble.social/ has launched DM support, implemented as NIP-17 DMs on top of NIP-4e (https://github.com/nostr-protocol/nips/blob/per-device-keys/4e.md). At the moment only coop supports this p...
 arthurfranca profile picture
arthurfranca @arthurfranca
NIP 4e is interesting but is rotating the encryption key regularly really a good idea?

If you decouple encryption from you main key and rotate encryption keys at will, there's no punishment to leaking conversations because revealing the message does not reveal the peer's main private key, just that disposable encryption key.
2❤️1
Jumble · 9w
Regularly rotating encryption keys isn’t really a good fit for a web client like Jumble. Users often access it across multiple devices, and sometimes even across different browsers on the same device. If one instance rotates the encryption key, syncing becomes messy, and users usually have no idea...
🦇 ݁ ˖ִ ࣪𝔉𝔩𝔬𝔴𝔢𝔜♱ ⠀ · 9w
The key is not rotated regularly, the user needs to decide when to do this.
arthurfranca profile picture
Breek sdk powers many bitcoin wallets. They are rolling out a way to store seed phares that is identical to how we already storing nostr keys at https://44billion.net

They use a client-side passkeys flow so that you don't have to remember your seed, although you may export it at anytime.

However, we went a step further to make sure we can never steal your keys even if we wanted to. The vault (login module) is on a separate domain we don't control. By default it is on Github Pages. You may point to your own fork there or to your self hosted version anywhere by changing the url on the settings page!

You can read the breez blog post here: https://blog.breez.technology/no-seed-no-sweat-introducing-passkey-login-for-the-breez-sdk-2cb7a7ee0279
And check out or fork our vault source code here: https://github.com/44Billion/44b-vault