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

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?

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