I believe this fits squarely into the “Other Stuff” part of NOSTR.

I don't see why it should be a problem that there are NIPs for things we won't use ourselves, or that people might shoot themselves in the foot with. Self-sovereignty is tough. There are benefits and drawbacks. We are OK with someone having their life savings on a piece of paper shoved in the drawer, but not with somebody backing up and sharing their own medical data?

Yeah, maybe they screw it up and it causes a huge problem in their lives (in either case). But the option is still there because it's all part of what it means to have the choice of self sovereignty.

In any case, the NIP itself should be judged on whether it meets the standards required for a NIP, not on whether or not we think it's a good idea.

Reply to this note

Please Login to reply.

Discussion

I also wonder if it changes if you think of nostr as a communication and not a storage layer. For example maybe each hospital runs a private relay and is responsible for securing and managing access to it. But what nostr would allow is a common way to request and transmit that data enabling better sharing and transparency among medical providers. But maybe that's stretching the scope of nips and bit and should be defined elsewhere. But I think it is an interesting use case and relay set ups other then publicly available should be considered.

I definitely think there will be good use cases for private relays. For one thing a company-internal relay that functions as a Slack, but can take advantage of the whole nostr ecosystem in terms of clients and integrations, etc. It wouldn't be too hard to do either. The socket handshake would just need to be authenticated with a signature to prevent unauthorized access. Maybe data should be sent encrypted with the private relay's own pubkey as well so that it's not accidentally shared to other relays.

I see no reason why a medical company couldn't use this kind of protocol to have a private relay while maintaining excellent data security and keeping the end user in control.