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"
>>   ],
>>   "hash":
>> "d1a8fafad6f073879a61cba2131c193a96f946caa57d244b1584816ccfc1f6cf",
>>   "actor": {
>>     "id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
>>     "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).
>
> 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?
>

The other important thing is that the w3c stack has accumulated some
technical debt over the past 25 years, leading to a steep learning curve,
and challenging devX

http://scripting.com/manifesto/rulesforstandardsmakers.html

Nostr is inspired by Dave Winer's simplicity principles for standards
development.  This has proved extremely popular with developers and a first
class devX, with high retention.  I find the pace of innovation on nostr to
be staggering.


>
> bob wyman
>
>