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

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?

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?

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/>.

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.

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
>>
>>