Greg Heartsfield
Greg Heartsfield
My main concern with this is that it basically reserves the tag "m" from all other kinds, even if they do not want to participate in multicast. I am still...
Sure, one could imagine a system in every client ran a relay. But since most clients do not have stable IP addresses, domain names, or SSL certs, and may have...
This is partly a server/relay issue (will your data be available _somewhere_?), and partly a client (especially native client) issue. It sure would be nice if clients kept all your...
I am less enamored by this NIP everytime I think about it, and generally prefer the idea of some other higher-level way to link accounts (example, metadata in a user...
I am saying that, unlike the delegation restrictions that actually prevent a delegatee from posting kind X when only authorized for kind Y; there is no way for a relay...
I think this feature exposes too much of the underlying relay state and complicates the subscriptions for clients (exposing two different timestamps). I'd much rather stick with a simpler model...
I only have a mild dislike, mostly because the simplicity of nostr has a huge appeal for me. That said, we can implement this with no changes for existing clients,...
I'm in agreement as well.
Is it better for kinds to opt-in (as part of their NIP) to non-replaceability? And then have relays ignore the `d` tag (if one exists) in those cases? Agreed that...
Agreed on splitting & squashing. Splitting out any Github build improvements into a separate PR would be appreciated as well.