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

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?

bob wyman