Re: Why is Nostr useful? What can Nostr do that ActivityStreams can't?

pá 12. 5. 2023 v 1:14 odesílatel Bob Wyman <bob@wyman.us> napsal:

> Melvin suggests:
>
>> Maybe use nostr:pubkey:hash here
>
> As far as I know, "nostr:" is not a registered URI scheme even though it
> is described in NIP-21
> <https://github.com/nostr-protocol/nips/blob/master/21.md>. Is there a
> plan to get it properly registered?
>

Hi Bob, thanks for raising these points.

The nostr: URI scheme is still in early stages.  We've discussed it a few
times on the developer channel.  They bech32 npub key format is designed
for the front end for copy / paste, an attractive alphabet, error
correction, extensibilty and so on.  It's been a great choice and popular.
The back end canonical form uses hex keys.  Anyone that has written a
bech32 or bech32m library will know it's no walk in the park.  Nostr is a
community of builders, write code first and gain adoption, then formalize
it with a registration is the more common path.  But documenting the key
formats is a good idea, and I'll try work on that soon.


>
> https://nosd.link/did # just a rough draft
>
> What would a did:nostr method do that did:key doesn't do? If they are both
> nothing more than methods for publishing a public key, I can't see how it
> makes sense to introduce a new did:method. We've got too many already.
> Would the did-document inferred by using the did:key did-method work with
> Nostr? If so, why not use did:key?
>

did:key uses multihash, which is an extra moving part for nostr, an extra
library, and unnecessary.  The did sketch is just a starting point though,
and there are a few other things that can be added, such as relays as
service points.  The key part is the simpler wrapper around nostr's truly
decentralized identifiers (ie with no http dependencies) so that it can
interface with systems that use did methods.  More work will be needed
there, and is ongoing.


>
> In any case, as I pointed out earlier, I'm concerned that the use of raw
> keys will present future migration problems if it ever becomes necessary to
> switch to other hash methods. I would prefer something like the multi-hash,
> multi-code hashes that IPFS uses as CIDs
> <https://docs.ipfs.tech/concepts/content-addressing/>.
>

I've been interested in standarizing multihash/CID for a while.  It's an
early ongoing project with the mh:// URI scheme at the IETF.  Multihash CID
borrows from the legacy base58 system and nostr itself has moved on to
bech32.  There's a lot of literature on why bech32 was selected over
base58.  From a "vanity" standpoint it has proved popular.  Nostr uses
taproot and schnorr as its fundamental identity system.  There is a massive
eco system around that, including some of the best cryptographers in the
world.  Time will tell whether that's the best choice, but it's here to
stay in nostr.


>
> Maybe use: https://w3id.org/nostr here, work in progress, but I hope to
>> get it to 0.1 in w/ the nostr CG
>
> Your draft Nostr profile defines, as it must, "content" and "event." But,
> those terms conflict with the existing ActivityStreams vocabulary. While
> the conflict can be worked around, I was trying to think about how I would
> do Nostr-like-stuff in ActivityStreams. Building gateways was not my focus,
> although I recognize that it would be a reasonable, and potentially quite
> useful, thing to do.
>

Linked Data was precisely created to prevent such name clashes through name
spacing.  So long as AS does not introduce centralized @protected "sacred"
terms, then all vocabs can live with each other.  Nostr hopes to have the
highest quality so-called "5 Star" form of Linked Data, with the help of
expertise at the W3C.  I'll note at this point that the activity streams
Vocabulary is not currently even machine readable.  I am hoping the Nostr
vocab will be, because that is the whole point of linked data.


>
> bob wyman
>
> On Thu, May 11, 2023 at 6:43 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> pá 12. 5. 2023 v 0:27 odesílatel Bob Wyman <bob@wyman.us> napsal:
>>
>>> It seems to me that I should be able to use ActivityStreams, with minor
>>> extensions, to do anything that Nostr allows me to do. Am I missing
>>> something? If not, why are so many people proposing to layer new
>>> application protocols on Nostr and not ActivityStreams?
>>>
>>> For instance, if I wanted to do "Nostr-with-ActvityStreams," while
>>> keeping the Nostr convention that one is identified by one's public key, I
>>> might produce messages that looked something like:
>>>
>>>> {
>>>>   "@context": [
>>>>     "https://www.w3.org/ns/activitystreams",
>>>>     "https://example.com/ns/pubsub"
>>>>
>>>
>> Maybe use: https://w3id.org/nostr here, work in progress, but I hope to
>> get it to 0.1 in w/ the nostr CG
>>
>>
>>>   ],
>>>>   "hash":
>>>> "d1a8fafad6f073879a61cba2131c193a96f946caa57d244b1584816ccfc1f6cf",
>>>>   "actor": {
>>>>     "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
>>>>
>>>
>> Maybe use nostr:pubkey:hash here
>>
>> or if you have to use did (but its worse), something like:
>>
>> https://nosd.link/did # just a rough draft
>>
>>
>>>     "relay": "some.relay"
>>>>   },
>>>>   "type": "Note",
>>>>   "content": "My dog has fleas.",
>>>>   "published": "2015-02-10T15:04:55Z",
>>>>   "sig": "1e465884718a89d6bf3c81e9beb7d638ab1f35900537"
>>>> }
>>>
>>> That example provides most of what's in Nostr's NIP-01
>>> <https://github.com/nostr-protocol/nips/blob/master/01.md> basic
>>> format. There are, of course, some differences. For instance, the various
>>> Nostr tags aren't there, but their content could be easily computed by
>>> looking at other AS properties. Also, I've called the Nostr "id" the "hash"
>>> in order to avoid confusion with the AS id ( which must be a URI).
>>>
>>
>> I've not thought about this in great depth.  This looks not bad, but
>> would any server accept it?
>>
>> There's also the proxy object FEP, and mostr does something similar
>>
>> I'm all for expanding bridges, and we are hoping the fediverse bridge
>> will get some funding too (fingers crossed!)
>>
>>
>>>
>>> The AS message would use more bytes than a Nostr message, but the excess
>>> isn't significant.
>>>
>>> Personally I find Nostr's use of public keys as identifiers to be one of
>>> its weaknesses since it means that you have to change identities if you
>>> lose, misplace, or rotate your private key. So, if I want to stay more in
>>> line with normal SocialWeb practice, I might use an actor.id of "
>>> acct:bob@example.com, instead of a raw public key. My assumption is
>>> that someone wishing to verify the signature would use WebFinger, or some
>>> other means, to retrieve my current public key. Of course, if I used a
>>> did-method other than did:key, the fetched did-document would specify the
>>> appropriate methods to use in verifying the signature.
>>>
>>> I'd want a few other departures from the way Nostr works. For instance,
>>> I might not be comfortable with the required use of sha256 as the hashing
>>> algorithm. So, I'd probably specify that the hash format should be like IPFS'
>>> muliti-hash, multi-codec content identifiers
>>> <https://docs.ipfs.tech/concepts/content-addressing/>. This would make
>>> migration to new hash methods much easier in the future. It would also
>>> ensure that all messages had globally unique identifiers and even that we
>>> could use IPFS-like or other DHT methods to store and retrieve them.
>>>
>>> The result of these changes would get me a simple messages looking
>>> something like:
>>>
>>>> {
>>>>   "@context": [
>>>>     "https://www.w3.org/ns/activitystreams",
>>>>     "https://example.com/ns/pubsub"
>>>>   ],
>>>>   "cid": "QmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n",
>>>>   "actor": {
>>>>     "id": "acct:bob@example.com"
>>>>   },
>>>>   "type": "Note",
>>>>   "content": "My dog has fleas.",
>>>>   "published": "2015-02-10T15:04:55Z",
>>>>   "sig": "1e465884718a89d6bf3c81e9beb7d638ab1f35900537"
>>>> }
>>>
>>>
>>> The remaining task would be to define a syntax for subscribing to
>>> messages. While Nostr's method requires crafting disjunctive normal form
>>> lists of fields and values, I personally would prefer if clients exposed a
>>> human-readable, parsed syntax more like what folk are familiar with from
>>> search engines. (Of course, these queries would be compiled to DNF
>>> internally.) For example:
>>>
>>>> "actor.id = acct:bob@example.com AND type = Note"
>>>
>>>
>>> Given the AS-extensions outlined above, I should then be able to modify
>>> either existing Nostr relays, or ActivityPub servers, to support these
>>> messages. And, anything that was defined for Nostr should be easily ported
>>> to this message format as well. So, why do I need Nostr?
>>>
>>> bob wyman
>>>
>>>