I've installed 3 Chatmail clients on my phone today (I think Chatmail is the name of the protocol, but everybody calls it Delta Chat, but then Chatmail doesn't present itself as an interoperable protocol either, it presents itself as a collection of software projects and it's unclear whether Delta Chat is part of it or a spin off):
- Delta Chat
- Arcane Chat
- WhatsDown
The 3 are basically the same app. I didn't check but they probably share 99% of the codebase. I don't understand.
Also they allow you to share an invite link for others to talk to you, but I couldn't take the invite link from one and paste on the other because there is no place to paste, only a place to read a QR code.
It's not clear whether I'm supposed to share this invite link publicly or if it's a private thing for only one person to message me (the invite link is big and full of metadata in it). If it's private how am I supposed to send it to someone, using another messaging app?
Also apparently they create accounts for you in a random chatmail server, or Delta Chat at least seems to do that, while Arcane Chat seems to always use arcanechat.me (or something like that), so that could be the reason why they have different apps that are almost exactly the same: the hardcoded setup parameters.
fiatjaf
_@fiatjaf.com
npub180cv...h6w6
~
More things on the latest version:
- new flag "--jq" runs a jq interpreter inside #nak with Nostr-specific functions that can be used to easily extract tags from events, pretty-print dates, extra-filter the list of returned events and more, see the README
- "nak profile --name/--picture/--metadata" for easy automated name fetching in case you need that
- the default key is not '01' anymore (breaking change!), now the default key is a pseudorandom key derived from your machine id and other machine-specific properties (this is not perfect or secure, it's only for testing), call "--nak key default" to see yours and set $NOSTR_SECRET_KEY if you want a permanent default
- same for the "--connect-as"/$NOSTR_CLIENT_KEY, it defaults to the same
- you can specify "--auth" when running a bunker or when connecting to a bunker to sign your event and nak will authenticate to the relays if required
- "nak serve --auth" runs a relay that requires AUTH from everybody (but doesn't do anything with the information except printing it)
View quoted note →
GitHub
Release v0.20.0 · fiatjaf/nak
a command line tool for doing all things nostr. Contribute to fiatjaf/nak development by creating an account on GitHub.
Instead of polluting all the events with a "client" tag can you guys please agree on publishing a kind:1729 event (I just made that number up) with the client name in it every day or every week or who knows?
Then you can have your popularity contests without forcing everybody to store and download millions of extra bytes.
Also please remove the useless "alt" tags (specially from kind:1), that experiment has failed.
grimoire - a nostr client for magicians
The most recent #pyramid version has things that you may have not heard about:
- /database page for direct database querying for the admins, along with a button to delete events arbitrarily
- same thing on the blossom side, admins can micromanage and delete things (previously users could already manage their own blobs)
- I have probably mentioned this already, but we have tiered limits for blossom uploads, like you can say "1000/500/200" so people on tier 1 (right below the admins) get 1000MB, people on tier 2 get 500 and people on tier 4 get nothing
- pomegranate operator service (be a partial key custodian for your community)
- a way to request access -- this has to be enabled, but then anyone can request to be invited by anyone else that is already a member on the relay (and has invites available) from the home page, and people can accept or reject also from there
- the relay itself publishes a kind 0 for its own key (I don't remember why this was necessary, but it will look nicer when browsing special relay-made events from other clients)
- an nsite gateway for assets and manifests published on pyramid, see https://npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6.nsite.pyramid.fiatjaf.com/ for example
- I have probably mentioned this already, but there is a /clients page that lists all clients connected to the relay, for admins only
Join us at get it from
and be forever happy
Nostrord
GitHub
GitHub - fiatjaf/pyramid: a wondrous furnace of communityzenship backed by a dynamic ladder of socialhood
a wondrous furnace of communityzenship backed by a dynamic ladder of socialhood - fiatjaf/pyramid
The most recent #nak version has things that you may have not heard about:
- "nak nsite" command for downloading and publishing nsites from a directory
- most commands now take --sec, --auth, --force-pre-auth flags so you can AUTH when publishing an nsite, for example, and the syntax etc is all shared (please report bugs)
- "nak nip" command for displaying NIP text, pretty printed
- "nak kind" command for displaying information and schema about a kind, with data sourced from
(please contribute)
- when specifying a kind in any command you can pass a string and it will match a kind number, try for example "nak req -k 'fav relays' -a cody@jumble.social --outbox"
- a bunch of fixes, most by @mattn, and some minor flags added here and there
Download at 
GitHub
GitHub - nostr-protocol/registry-of-kinds
Contribute to nostr-protocol/registry-of-kinds development by creating an account on GitHub.
GitHub
Release v0.19.13 · fiatjaf/nak
a command line tool for doing all things nostr. Contribute to fiatjaf/nak development by creating an account on GitHub.
Writing specs with uppercase words SHOULD/MUST/MAY is stupid.