Am I understanding correctly that you can't reuse your existing npub for this unless you're using it with DENOS?

If I understood your question right: You can use remote signers (nostrconnect:// / bunker://) like Amber or DENOS (or Primal now?), local PC signers and with username/pass like DENOS, browser extension, or import your 24 words or nsec for local use, or generate a new one. Basically all popular options are there + the stuff I made (pc local, username/pass, dnn)

I genuinely don't understand how to import the nsec :pepetard:

Okay, I figured it out. I dare say it's buried a bit deep.

Trying to view the feed of my existing account just makes DEN chat (the linux appimage version) freeze :V:

Was it? it's on the front page "import" Was there some bad flow that led to a confusing outcome?

I'm messing around with it as we speak. This is awesome.

Linux bug 1, noted x3 I'm using Tauri to make builds, instead of Electron, and apparently Tauri isn't that good with Linux, so I'll probably need to fix a bunch of issues with it on that OS.

I don't remember if that was the original state but now (after making 1 new account) it only shows me the import button if I go to the saved accounts first.

Aye, to save on vertical space, the "Import" and "Generate" buttons gets moved into "Saved Accounts", where you can import a seed or nsec, or generate a new seed, like before, or if you had a seed you can derive from it new addresses (no need to make new seeds).

Will your n-mail implementation be compatible with NostrMail?

Didn't look into it, but if it's nostr to nostr, (not a bridge from traditional email to nostr), and seems fine structure wise, then sure, otherwise probably not.

Here's the link to the NIPs they use:

Nostr Mail | The Open Protocol for Decentralized Email

The open, sovereign and decentralized email protocol powered by Nostr. Own your identity and inbox without central authorities or gatekeepers.

Also is there any way I could get PR access? I'd like to contribute to this.

Still haven't got arround to get familiar with gitworkshop yet, and so i'm using github or gitea, but for this i'm using github and on this account temporarily until i get things organized elsewhere, but ya here's the link if you want to check things out:

GitHub

GitHub - Freakoverse/den-chat

Contribute to Freakoverse/den-chat development by creating an account on GitHub.

(side note: if you read stuff about 'filter relay' i might not do it, still thinking about it)

Sweet, I'll check it out. And the gitworkshop stuff is peak. You just run `ngit init` and then use normal git commit/pull/push.

I added it to my to-do list to test! How does “history” get saved? It’s built on NOSTR so in theory if a similar app to Denchat is created, one would just log in and the app (client) would grab all the content from relays? Or no…it’s Denchat or bust?

I got a continuous series of nip04_decrypt failed: invalid base64, using @Clave Maybe it’s a good idea to have some exponential backoff/throttling when the signer fails? I’m sayng that because Clave relies on push notifications to work and boy, my phone did not have a good time when I logged in and the errors started coming through.

From relays, nothing central.

Looking into it. I wouldn't be able to test with Clave, so once an update is out, try again and see if things improved. (btw how is Clave? I got someone asking me for iOS signers to recommend)

Other than the 5 clients per nsec limit, I have no complaints. Been using it since the first TestFlight release.

Decrypting DMs is an issue with any remote signer that uses NIP-46, because each decrypt request has to round-trip over a relay for every single message. And modern (NIP-17) DMs are giftwrapped, so each message is roughly two decrypt requests instead of one — the client has to unwrap the giftwrap and then the seal, both round-tripping to Clave. So an npub with a few thousand messages (totally possible) means several thousand round-trips, which can take a few minutes even in the best case. @Clave connects directly to relays when the app is foregrounded and processes requests in parallel, so if you're logging into a client for the first time, I'd recommend keeping Clave open (obviously a challenge if the client is on the same device). When Clave is backgrounded, it goes through the iOS notification service extension, which is more constrained — iOS gives each wake a hard ~30s budget and only a handful of requests get handled per wake, so a big backlog can stall and take much longer. Foregrounding is by far the faster path. Ultimately though, it's up to clients that support DMs and NIP-46 to figure out ways to avoid trying to decrypt an entire DM inbox over the wire in one shot.

Aye. I'm basically adding a sort of guard so it doesn't blast the user with requests / finding a good balance with UX for this.

DMs should only be requested to be unencrypted when viewed and per note but I’m guessing that’s to granular for most users…

It’s also good to note that, if it weren’t for the base64 error, notifications would be delivered silently straight to the Notification Center, so even if there was no denouncing, I wouldn’t have noticed the influx of events.

But with gift wrapped DMs you don’t know who the dm is from until you decrypt…

I’d recommend turning off lock screen and Notification Center. Clave needs notifications enabled to work in the background, but IMO you just need banners to get notified of a protected event that a client is requesting you sign. The requests time out after a while anyway so no point in showing in your Notification Center. And if you want to see activity just check the activity feed in clave.

Good call. Now, could setting the banner style to persist would force concurrent sign requests to be queued by iOS? I know temporary replaces the current banner with the latest push as soon as it is received.

Surprise!