Nostr Web Client

Authentication matters, meta data leaking problems matter.

Technically, NIP-42 solves authorization, not authentication.

I can't speak for other developers. Blowater left out NIP-42 because it does not fit into how Blowater wants authorization to work. Blowater has its own design to mitigate metadata leaks problem (which does not fully address it yet). This design does not have to interop with other clients because other clients are not likely to address the same set of features anyway.

There is no universal authorization scheme that works for all software. I have implemented multiple SaaS product in my career and have worked with many 0Auth providers. If this problem is simple, it won't be a multi-billion market.

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 1y ago

How does Blowater want authorization to work?

Water Blower 1y ago

You asked the key question.

The future Blowater will be more like Discord and treat each relay as its separate place.

First of all, it need roles.

Relay Owner, Relay Admin, Normal users etc

If we also assumes that relays don't need to update its code to support special client features. Then, I would like to have relay owner sending an event that describes all kinds of resources & roles relevant to this client, such as

{

roles: {

admin: {

write: "all"

read: "all"

normal_user: {

write: ["resource_1"]

read: ["resource_1", "resource_2"]

}

then, in the tag of kind-1s and other events, blowater will attach the resource type

{

tags: [

["resource_type", "resource_2"]

]

}

Something like this. It's like a type system for resource access control.

If relays do not support it, Blowater can just do it on client side.

Of course, it's always better if some relay implementation support it. This is another reason that I am writing a tiny JS relay implementation. I can do this kind of end-2-end expriment quickly.

But Blowater does not even have these features yet. So it's not an immediate problem to solve yet.