Interesting. But I think #NIP98 has just been made obsolete by the #IETF publication of HTTP Message Signatures . That provides a way to sign HTTP headers with keys, and there is no reason one could not use the keys that #nostr uses, by either publishing them at an http location or using a #DID URI (did:key, or did:jws, ...) . But you are right that it is similar to foaf+ssl, or WebID-TLS, though much more flexible in fact, since TLS can only sign the connection whereas message signatures can sign every request, and every request differently. I show how "Message Signatures" can be used to speed up #BigData access to #LDES files in this demo.

Replies (2)

It can be challenging navigating the complexity and lengthy approval processes inherent to some committee-designed systems. Often, there are discrepancies in compliance with linked data standards and some essential terms may be overlooked. For instance, the use of lowercase hex for canonical pubkeys, a seemingly intuitive choice, is now deprecated in the security vocabulary Creating first class linked data in nostr I think is a better approach, and focusing on things that work, as well as bridges to systems with network effects. NIP-98 is working well and opening up new use cases. It is cleaner than JWT because it doesnt have the query string duality, just like all those uris that for a decade had session strings. And a 2 page spec is easier to implement than a 100+ page spec. There might be some overlap that can be explored in future.