Has noStrudel updated yet? Last I checked, it was still on NIP-04, too.

This is how:

NIP-17 DMs with relays that require auth would be a decent spec. Problem is, not all clients follow it, and the most popular client is still using a spec that was deprecated nearly 2 years ago.

If your church doesn't have an evening service, end your Lord's Day with the Word of God preached. is streaming on zap.stream. https://zap.stream/naddr1qqjrwefhxuexycmx95crgdpn956x2de5943xyerx956n2cesxqcx2epsx5exgqg4waehxw309aex2mrp0yhxgctdw4eju6t09upzpn6956apxcad0mfp8grcuugdysg44eepex68h50t73zcathmfs49qvzqqqrkvutrkx7q

Sunday School on zap.stream! https://zap.stream/naddr1qqjrsc3kxcmxze3395mrvc34956ryvrz943rwd3j95uxvvmpx9jxzvfsx56nvqg4waehxw309aex2mrp0yhxgctdw4eju6t09upzpn6956apxcad0mfp8grcuugdysg44eepex68h50t73zcathmfs49qvzqqqrkvuq7qhf0

Your nsec is never stored on Alby's servers. It is stored locally on your device only. This can be seen easily by simply logging into Alby extension on another web browser. It will not have your nsec set up in the Nostr settings.

10k sats/year or 1000/month. I chose yearly.

Who would go in with me for putting out a bounty for someone to package Haven realy for Umbrel, with a GUI for editing the necessary .env variables? Haven is intended to be a relay for individual users, so they have their own public outbox, public inbox, DM inbox, and private relay, plus their own Blossom server, making them effectively censorship proof, especially if their relay can run behind Tor. The only issue is, setting it up is not user-friendly, so only those with some significant technical chops end up running it. I am prepared to put 100k sats toward a bounty for a one-click install version of Haven for Umbrel, with a GUI for configuring relay owner NPUB, relay icon, blastr and import relays, etc. Anyone else who would like to see this happen and would be willing to add to a bounty? #asknostr

Ah, thanks! would you mind giving me a rundown of how to get Haven running via Portainer on Umbrel? If I can get it figured out, I will probably write and release a guide for others.

I just logged into it to confirm the above was still the case. At least, I don't see anywhere to add any of the above. Also noticed that it still has my "Declaration of Independence" note at the very top of the home feed. I guess they haven't figured out how to filter notes from the feed with timestamps well into the future. 😂

Ideally, someone would just package it for Umbrel, with a nice GUI for modifying the .env settings. Not holding my breath though, and I have no idea how to go about it. 😂

I tried out Yakihonne, but its composition screen is missing a couple things. 1. Nowhere to add a title image. That is, unless it is just taking the first image you add into the body of the article as the title image? 2. Nowhere to add a short description of the article. 3. Nowhere to add tags, except the body of the article itself.

I thought you might, given that you maintain the repo for the unofficial docker image. Or that you might know some folks that have used Portainer to run that image. If not, no problem. Hopefully someone else will be familiar with the process.

Primal isn't bad, but Longform is clean and uses standard 30024 for drafts.

or anyone else who might know. Is there a guide anywhere for getting the docker version of Haven up and running on Umbrel using Portainer? If not, would someone with the know-how be able to give a rundown? #asknostr

Longform._ is truly a pleasure to use for writing and publishing long-form notes. Great job with this client ! I am very happy to support your work!

I don't think having the sender metadata leaked is an issue, if the message is only sent to the recipient's DM inbox relay, and that relay supports auth to ensure only the recipient can request the message. I don't think NIP-4 uses NIP-44 for encryption, though, right? Would it be better to use that updated encryption standard, at least? Then, yes, users could have a relay that they set a required price to post a DM to them. Users who have the know-how would be incentivized to run a relay where they get paid anytime someone wants to DM them. The rest of users would have to rely on relays that take a cut of the payment, or else deal with spam.

I am not aware of a "multitude of specs." I know of three. 1. NIP-04, which should only be used with auth relays, due to the metadata it leaks about both sender and receiver. 2. NIP-17, which definitely has the shortcoming of being unable to filter DMs based on who the sender is, since the metadata with sender info is hidden. More private, but yes, more susceptible to spam without some other mitigating factor. 3. NIP-EE, which uses MLS and may well be the future of DMs and group messages, but is not yet ready for prime-time. There are a couple clients that are doing a bit of their own thing, too, like , but that's outside of any NIPs that I am aware of. As far as whether I find any problems with your argument, only a couple. First, you already identified why it will never happen. Users expect to be able to DM for free. Requiring payment to send a DM is a fantastic way to reduce spam, but only if users are on-board with it. I also don't think it would result in a convergence on a particular spec. If anything, I think it would result in more fighting about it. You would have folks like us on one side, shouting about how requiring paid "postage" is the most effective way to reduce spam, especially if users themselves can set the amount of postage required to DM them, while others would be shouting about how making people pay for things is a barrier to adoption, and stubbornly keeping DMs in their clients free for everyone. Heck, Keychat is already an example of a client that has MLS-based DMs with paid postage, yet its existence hasn't resulted in every other client converging on that spec, because most users simply don't want to pay to send a DM, even if it would mean they receive less spam.

Not all "Protestant" churches are created equal.

You just successfully argued against your proposed solution. I agree that requiring payment per message would solve the spam issue, but it wouldn't necessarily solve the "different clients use different DM specs" problem. Indeed, it would just make it worse.