There really needs to be a way to replace or update a did:nostr or nostr pubkey...

Can you suggest what requirements should be addressed by a useful decentralized discovery system? Or, if you know of a doc(s) that already outlines them, can you provide a link to it or them?

#[0]

Jack, thanks for supporting Nostr. I'm not sure if you'll remember PubSub.com, back in the early 2000's... But, it strikes me that Nostr comes closer than anything else I've ever seen to what it was that I was trying to build at PubSub. The simple PubSub model offers vastly more power than most have recognized. I'm hoping that Nostr is successful in achieving what I failed to do earlier.

Advertisments, forced into my feed without my consent are certainly undesirable, but the PubSub nature of Nostr would seem to naturally support an exchange of "Offers to Sell" and "Offers to Buy." Given a sufficiently robust ability to REQ, I should be able to subscribe to receive "Offers to Sell" for some specific item or service, potentially with some set of characteristics determined by me. For instance, I'd like to be able to publish an "Offer-To-Buy," or subscribe to receive "Offers-To-Sell, for a "Model X SmartPhone with XXX memory for less than $XXX, delivered to my address in Zip Code before XX/XX/XXXX." Ideally, I would only see offers which did, in fact, match my Offer-To-Buy or my subscrption to Offers-To-Sell. A similar pattern could support a wide variety of exchanges.

This isn't quite "advertising," but it would be a means to accomplish at least some of what is the purpose of advertising: matching potential buyers with potential sellers.

BTW: Melvin, given that you've long worked with W3C projects, and that you're a member of the SocialWeb Community Group, I would be curious to understand why you've invested so much effort in Nostr rather than W3C protocols, such as ActivityStreams/ActivityPub. What advantages does Nostr have over the W3C standards? What can you do with Nostr that you can't do with AS/AP or other standards?

Melvin, can you say anything about how you expect the community group to be run? As chair, will you be setting some kind of agenda? Are there any work-products that are expected? Will you host meetings from time to time, or will it all be written?

#[0]

I'm using Gossip, which doesn't seem to support sending encrypted messages. So, I can't reply in kind. Can you propose a more functional client to use on Ubuntu?

> How can nostr be slotted into current email tech?

I'm not sure the question makes sense. Cramming everything into email or everything into Nostr wouldn't be useful. The essential point is that the "shape" of one-to-one, one-to-many, and many-to-many communications are naturally different and are best supported with different UI metaphors -- even if the differences are subtle. Also, "sender-decides" and "receiver-decides" are distinct communication models that require different mechanisms. One might have a single application that could properly serve each of the "shapes," but that would be simply an optimization.

Of course, there are some obvious technical things one could do. For instance, it seems reasonable that one might replace POP with Nostr for last-mile delivery. The result would be something somewhat like IMAP. But, you wouldn't want to replace message transport protocols with Nostr. Email's ability to do store-and-forward routing of messages with an explicit destination is very important for the kind of messages best suited for the email paradigm. Often, those messages require a reasonable guarantee of delivery. (i.e. If I'm sending you a contract, I must be sure that you'll receive it and see it.) I think many of Nostr's other applications can be more forgiving about delivery guarantees and they don't need to ensure that you see all messages that might have been accessible by you.

The big differences are in the user interfaces. For messages that really should have been sent via email, it is reasonable that I should have an interface that provides a lossless, potentially permanent, store of messages both received and sent. And, it is reasonable that the interface include mechanisms intended to ensure that I see everything that was sent to me. But, the kind of communications that occurs in at least in what I think are the existing uses of Nostr is more likely to be ephemeral. While a permanent record of Nostr messages might be useful, it isn't essential in the same way that it is with email.

Many mailing lists are, I think, good examples of something that we do with email but that we really shouldn't. When Google Groups came out, I was really hoping that it would help put an end to many mailing lists. It seems to have had the opposite effect... I'd like to see more of the one-to-many stuff move out of email. The needs are different. For instance, my email system will typically only provide me with messages received since I started using it for a particular list. On the other hand, with many lists, it is useful to be able to view content published before, even long before, one subscribed. Email can't do that. Other patterns can.

But, I'm wandering in this note. The key is that we need to accept that not all messages are the same. We need a variety of methods for dealing with messages having different needs. It is time that we stopped trying to squeeze everything into email, or into any other application pattern.

bob wyman

I first worked on implementing email back in the late 1970's at DEC. (Old folk may remember DEC ALL-IN-1...) Even then it was obvious that while email was, and would remain, tremendously useful, people tended to use email for too many things. The problem wasn't with the protocol for pushing blobs from one place to another, it was that developers tended to present all messages using the same interface metaphor whether for one-to-one messages, or for one-to-many messages. Also, we made a mistake in focussing almost exclusively on push-communications, where it is the message sender who decides who receives messages. We should have put more effort into pull-based systems that allowed message receivers to choose what they received. (i.e. PubSub or other subscription models, as in Nostr).

bob wyman