Unfortunately not currently supported, you can make a new one though. We'll see if we can fix that in an upcoming update.

Fedimint can do this pretty easily since it supports onchain. We have this in Ecash App https://ecash.love

I'm curious what Nostr thinks of privacy vs auditability in ecash mints. In Fedimint, all of the Bitcoin is held in an onchain multisig that is controlled by the guardians. In most deployments, this is a 3/4 (but it can be larger), which makes it painfully obvious onchain to third party observers. The UTXOs that a federation controls is also not private, they can be found by scanning the mint's history (which is public). This can be seen on https://observer.fedimint.org/ or using Ecash App (https://ecash.love). I think it is a nice feature to be able to see onchain all of the UTXOs that a federation holds (this could make something like proof of reserves easier). Now, in a world where Fedimint has a taproot wallet (instead of P2WSH) and can use FROST/ROAST to sign peg-out transactions, it is no longer obvious onchain to third party observers which UTXOs correspond to a federation, since they can be spent using the keypath which looks like a normal taproot single-sig spend. However, as mentioned above, the UTXOs for the federation are still public, so a "fedimint-aware" third party adversary could still scan the mint's history and figure out the UTXOs. I suppose we could come up with a scheme to keep peg-in UTXOs private from third party adversaries, which (with FROST) would have the benefit that it would be really hard to use onchain data and mint history to determine if a user is using a Fedimint. But this would come at the cost of easy auditability.

More info here https://bitdevsmpls.org/2025-11-04-socratic-seminar-32

6-8pm

Been a long time (~10 years) since I've looked at any graph database, and I've never used Neo4j (I remember fighting with Giraph though, had a hell of a time getting that to compile). I like this paper's assessment of graph databases: https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec2024.pdf TLDR is graph databases do have some performance optimizations over RDBMS due to the storage layout and optimized algorithms for common queries (shortest, ancestors, etc), but ultimately you can also represent a graph as a collection of tables. Recently some RDBMS systems have been adding graph-like query languages and have been optimizing joins for graph queries and they have been claiming better performance. If you're not doing large OLAP queries or using it for other purposes, Neo4j seems like a pretty good fit for a Nostr relay.

Fantastic TabConf. Sad I had to leave early. My favorite moment was when someone asked what his go to market strategy was