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

High level on why is nostr useful, by jack dorsey:

nostr has its issues. but for those who figure it out, it’s the most
powerful network that exists today. challenge is helping more people figure
it out.

likely most of that won’t come from social use cases, but rather the
microapps that @fiatjaf originally envisioned and folks like @PABLOF7z are
focused on building.

the power of this thing is the ecosystem part. it’s permission-less,
meaning anyone can build whatever they want, and it has a permission-less
global payment system readily available through bitcoin. but neither will
sell people on joining it.

if the apps built on top of nostr do valuable things, like
https://highlighter.com does, then every nostr app and use case benefits,
including the social clients.

this is going to be a long road, but one that fundamentally changes the way
people experience the internet. if it doesn’t succeed itself, it will
certainly inspire the thing that does.

https://primal.net/thread/note194n247lecqgcskk5rmmfgrapt4jx7ppq64xec0eca3s4ta3hwkrsex7pxa

Explainer Video (long, but easy listening and very fun)

https://www.youtube.com/watch?v=634DvERKauA


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