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

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

> Melvin suggests:
>
>> nostr itself has moved on to bech32.  There's a lot of literature on why
>> bech32 was selected over base58
>
> Bitcoin's reasons for using bech32 <https://en.bitcoin.it/wiki/BIP_0173> are
> excellent examples of why the W3C CCG's multiformats
> <https://github.com/multiformats> stuff is useful. Different hashing
> methods address different needs. While bech32 may address needs that are
> specific to Bitcoin-related systems, those needs aren't universal. For
> instance, Bitcoin applications expect users to be able to manually write
> down valuable identifiers (e.g. with pen on paper...). Thus, they prefer
> bech32 since its base-32 encoding only uses lower-case alphanumerics and
> thus avoids the potential for confusion when transcribing or reading
> mixed-case identifiers. Unfortunately, the use of any base-32 encoding,
> rather than a base-58 encoding, will result in a less bit-efficient
> encoding. Thus, bech32 hashes are inevitably larger than base58 hashes. While
> that extra length provides some value for Bitcoin users, it would offer
> no real benefit  for ActivityStreams users. Also, bech32 includes a
> checksum which makes it even longer and less bit-efficient. This is
> useful for identifiers that are subject to transcription errors and which
> are exchanged independently of the data from which they were derived. Of
> course, the hash of an ActivityStreams object is a checksum for the
> object. Providing a checksum for the checksum would be a bit excessive.
>
> Not only do different hashing methods serve different needs, one's
> understanding of those needs can evolve over time. Thus, Bitcoin started
> out with a rather cumbersome custom base-58 hashing method, and later
> learned that it didn't serve their needs. So, it became desirable to move
> to bech32. Enabling this kind of transition is the sort of thing that
> multiformats makes much easier than otherwise.
>
> Note: I'm not trying to defend base58. I only suggest that while bech32
> may provide value for Bitcoin applications, it isn't obvious to me that it
> provides much value for the kind of application that would use
> ActivityStreams. Nonetheless, one should ensure that bech32 could be used
> in some AS applications, if it were, in fact, useful. Thus, it would make
> sense to ActivityStreams to use multiformat encoding so that common
> ActivityStreams applications could use stuff like base58, while the
> flexibility to use bech32, or any other hashing scheme, was also supported.
> Of course, those who use uncommon hashing schemes should not be surprised
> when other systems don't understand what they've done.
>
> Nostr hopes to have the highest quality so-called "5 Star" form of Linked
>> Data, with the help of expertise at the W3C
>
> Is there some written record that expresses this "hope?" I haven't seen
> any evidence of such a hope in my reading of Nostr stuff and there is
> nothing in what I've read that indicates any intention to use JSON-LD, RDF,
> or any other W3C-defined format (Note: One of TBL's "5 Stars" is "use W3C
> formats..."). What am I missing?
>

Nostr is primary a websockets technology.  There's not a huge appetite in
the main standardization effort (NIPs) to move to HTTP type solutions,
however there is an intersection.  One of the reasons that I started the
community group was to try and ensure that the bits in the intersection are
as high quality as possible, and using best practices in the W3C stack --
cherry picking to a degree.  Folks interested in nostr have a great deal of
linked data expertise.  My hope is that that can be translated into 5 star
linked data.  Certainly ahead of where AS or DID is today.  AS doesnt even
have a Linked Data compliant vocabulary.  Let's face it the bar is not high.


> did:key uses multihash, which is an extra moving part for nostr, an extra
>> library, and unnecessary.
>
> Come on! The multiformat libraries, available in all popular languages,
> are trivial. And, their use isn't even necessary when using a common
> fixed-length hash method. You just prepend a few bytes to your hash and
> you're done.
>
> bob wyman
>
> On Thu, May 11, 2023 at 11:34 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> 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
>>>>>
>>>>>