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

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