This was about the server side setup, unrelated to your VPN. How are you hosting it?

Thank you for spotting that.

if you're compiling from source this should be working already: allowkind/listallowedkinds/disallowkind methods. It's not in the UI yet, and not released, but hopefully will be.

That is a surprisingly hard problem, unless I make you adopt those users automatically when deleting their parent. Or what do I do instead? If you're inclined to adoption you can do that manually already, by the way. You can have the same user be invited by multiple users currently, so if it is deleted in one branch of the tree it's still alive on the other. On https://basspistol.org there is an example of that happening.

Yes, I can make it configurable, but I never hit that limit myself, so please ensure that if you are running behind a reverse proxy you are passing the X-Forwarded-For header to the relay.

The links should be fixed in the latest commit. Thank you.

Try this: https://viewsource.win/fiatjaf.com/nostrlib

vnak v0.2.0 is now widely available: https://github.com/fiatjaf/vnak/releases/tag/v0.2.0

I forgot that that method existed. It makes things even better.

The easy script is just for people who don't know what a reverse proxy is. It tries to run things on port 80/443 and manages TLS certificates for itself. Normal people can download the binary directly, compile from source, do whatever. Nice that you got it running.

new features in the latest last #pyramid release: - primitive blossom support with a simple dashboard and upload button - if you just publish an event with a date in the future it will be scheduled and automatically released at that date - an option to automatically opentimestamp every note published to the relay - an option to set the maximum size of events allowed - many fixes

I have just invited and to https://basspistol.org/, please make good use of your new privileges.

The latest nak v0.17.4 implements support for managing decoupled encryption keys that fix NIP-17 completely, as per https://github.com/nostr-protocol/nips/pull/1647 See this amazing infographic that explains how it works: If you call `nak dekey --sec ` you'll generate a new decoupled encryption key that is stored locally and announced with a kind:10044 event. After that if you use `nak gift wrap` or `nak gift unwrap` that key will be used by default (when wrapping both keys will be tried if possible). If you run `nak dekey` on another device/client (or with another --config-path) that other device will announce itself as in need of the decoupled key, then you can run `nak dekey` again on the first device and it will automatically send the key to the second -- and like that the key is shared among all your devices. Call `nak dekey --rotate` to discard the current decoupled key and generate and announce a new one. Download here: https://github.com/fiatjaf/nak/releases/tag/v0.17.4

That's good to know. I guess we can have NIP-34 and two remote types: grasp and hashtree living together them. I hadn't thought about it that way.

I didn't look into it very deeply, my first impressions are that it looks good but I don't think the idea should be pursued because NIP-34 and Grasp are immediately compatible with other git tooling that already exists and that is a huge plus. Also hashtree seems to be much harder to implement and I'm a believer in simpler solutions and having dozens of implementations.

Please tell me you're sending DMs to the relays in the kind:10050 event for each target user.

Real Nostr clients don't require any servers, they can work completely on the client side. The fact that we have apps that still work perfectly well but are now inaccessible because a domain name has expired (or whatever) is some bullshit we inherited from the "web" world that we should try to circumvent, not embrace. There are multiple ways to circumvent these flaws and build true Nostr clients that can't be controlled by anyone, not even by their original author.

SQRL invented the anti-phishing public key cryptography based approach to website authentication many years ago. It was a beautiful spec of one page with multiple grassroots implementations. Then they decided that the simple "I sign something with a key" approach wasn't good enough, they also had to cover a bazillion other key management things in the protocol so they brought a team of academics that turned the thing into a 300-page unreadable spec that no one ever implemented fully. LNURL-auth basically reinvented the original simple SQRL version in 2019 and got many implementations and some traction within the bitcoiner realm. But at the same time another team of academics probably by paid by some evil people were creating Webauthn, i.e. "passkeys", which solves the exact same problem and works in the exact same way, although this time the spec is much bigger than even the worst version of SQRL and apparently designed to create centralization. It took them at least 6 years to get browsers and phones and some websites to start adopting this behemoth, but so far there are no answers to what is their real purpose or to the question: "what if I lose my phone?". https://www.youtube.com/watch?v=xYfiOnufBSk

That is the idea. I don't know what exactly you mean by a themed relay, but you can invite like-minded people and get them to do manual themed curation using the /favorites sub-relay. Or you can get them to talk to each other either in groups or in the /internal relay about some theme, like a community. Or you can get them to curate public posts submitted to the /moderated relay, ensuring those meet some standards. If you are aiming for a curated experience you must be more selective with who you invite, as anyone invited will have the power to curate decide what goes in the thing. But if you're aiming for a community to live inside the relay you'll want to be more liberal and get more people. Let me know if you need some crazy feature that isn't implemented yet.

Added a "spell" command to https://github.com/fiatjaf/nak - `nak req -k 777 -a [email protected] --outbox | jq` to see all spells - pick one and run `nak req -i c1214b196b3664bc7fc8c8dfaa082a24ed09b25028773bcae60fef8dfe6646fa -a [email protected] --outbox | nak spell --pub fiatjaf.com` to run it in the context of your user (replace 'fiatjaf.com' with your npub or nip05) - `nak spell` will list your previously used spells with ids that you can use to invoke them again: `nak spell spellcgk4u9c --pub fiatjaf.com` It's not super useful, but it is something.

On vnak it will authenticate to any relay provided that you have set a main secret key at the top. On nak you have to pass --sec and --auth. There is also --force-pre-auth for when the relay doesn't send an "auth-required:" message but you want to auth anyway.

"load profile" is for loading preexisting profiles created with "nak bunker --profile". That isn't well-developed yet, I should have probably hidden that button for now.