DEN Chat My attempt at a discord/ts/element/slack alt, built on nostr, event/blossom-based (not relay-based), with group encryption based on LKH, voice/video/stream based on Cloudflare (simple but centralized, free 10gb/month bandwidth) and Livekit (self-host but needs more effort and running cost) and both are encrypted, and there's spatial audio mode (i wanted this for a years). Notes: Is this a good idea with how it's built? Who knows let's see. Scaleable to millions? I tried to make it that way so fingers crossed. Is it actually any good to use? Hopefully. Give it a shot tell me what you think Are there bugs? Probably ya (speaking of, i fixed those in the video x3) Web and Windows version works, Linux .deb and AppImage (on ZorinOS) seems to work, didn't try others. Check it out:

Replies (28)

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)
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).
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: (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 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.
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)
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.
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.
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. image
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.