Hey there, everybody. I am currently putting together a ZCG application to harden frostd for production use: durable sessions, rate limiting/DoS resistance, multi-tenancy, observability, optional Tor transport. The plan is to upstream the work into frost-tools rather than run a separate server. A few things I’d like to get right before I write the full application:
Do team members need to be named and locked in at submission, or can I bring someone on after approval? Can they stay pseudonymous either way?
The T&Cs mention milestones being validated by “intended users or their representatives” — for infra/tooling work like this, who usually plays that role?
Is anyone already working on hardening frostd for production, at ZF or elsewhere? I would like to avoid duplicating in-flight work.
Is there a good contact on the frost-tools side to talk through upstreaming before I submit, so that part of the application reflects an actual conversation rather than a guess?
Which category fits best: Infrastructure, Security, something else?
I would appreciate any pointers, and would be happy to hear thoughts on scope too.
@iamroot this is adjacent to something I’m scoping myself, a coordinator service for FROST-based shielded custody (pre-application thread here: [56660]), so a few things that might actually help rather than a competing pitch.
On Tor: I checked frostd’s docs directly a few days ago and there is no mention of Tor, onion routing, or network privacy anywhere in them. Confirmed absent, not a guess. I’d actually asked @conradoplg this exact question in my own thread, whether a Tor transport in frostd would be accepted upstream or belongs client-side, and hadn’t heard back yet, so his answer here (not working on it, no short-term plans) is useful signal for both of us.
On milestone validation: I’m a real downstream user rather than a hypothetical one. My own coordinator work plans to run FROST ceremony traffic over frostd behind an onion service specifically, so if it helps to name a concrete intended-user validation path, I’m one, and I’d actually pilot it rather than rubber-stamp it.
On category: I went with Infrastructure for similar reasoning, ZCG’s framing leans that way for service/tooling work over a wallet-shaped Security bucket. Not authoritative, just where I landed.
No overlap I can see between what you’re scoping and what I’m scoping. frostd hardening is useful regardless of what sits on top of it, and my coordinator would sit on top of it either way, so happy to compare notes as both move forward.
For the Zechub hackathon recently, I pulled together a frost-based wallet application that might be of interest. Its really raw/hacked-together so definitely some optimizations that it could use.
I built into the application that the server portion users can either self-host or connect to a dedicated url. For the user that fires up the server (and will share with users) I made a disopsable cloudflared tunnel that creates a url for easy sharing. Definitely a place to improve would be to use something like Tor (if possible) or even tailscale for people that coordinate in a small group to make it work. Planning on scoping the tailscale serve portion within the tool here soon.
Thank you very much for your answer. Your ‘no-duplication’ reply is what I needed to move forward with my application.
I would prefer that we keep this conversation public, so I can include it in my eventual application. That said, would you prefer we move it to GitHub discussions/issues on frost-tools, or keep it here? The forum keeps everything public and would probably be easier for the ZCG committee to cite when they review my application. The repo discussion, on the other hand, would put the technical scoping right next to the actual code and all the maintainers, and will probably be the more natural long-term home once we are able to firm up the specifics. I am happy either way and would follow your lead, since you are the maintainer. My priority is for any discussion and decisions to be captured somewhere citable for the application.
On upstreaming: is it reasonable to write the application on the assumption that this hardening work would be merged into frost-tools, or is that something we should establish first? I do not want to presume merge acceptance before we have actually discussed it.
One of the developers has already offered to help validate the network-privacy piece. Would ZF be willing to validate the pieces you can meaningfully sign off on, such as session persistence, DoS/rate limiting, and multi-tenancy, or point me to someone who could?
I have one more scoping question, separate from the logistics above about decision I am trying to make is this: would a Tor/anonymizing transport be better living inside frostd, or client-side in the tools that use it? Unless I have read them wrong, @aryaethn’s coordinator and @uscmigs’s Cyze hackathon wallet seem to be independently reaching for transport privacy within their own apps, which hints the answer may be client-side. I would like your read before I scope that milestone.
Yeah my understanding would be that you could alter the way frostd communicates directly in the source… I’ve opted for the flexibility to manage privacy through the application layer… leaves it more open for implementation across different stacks or technologies. Tor is great but if the sources code is tied explicitly to it, you may bottleneck options that may want less latency… just my 2 cents
I agree there is no overlap. Your coordinator would sit on top of my hardened frostd either way, so it’s complementary. I’ll be very glad to compare notes as both projects move, and I am already following your custody-coordinator thread.
Thanks for confirming Tor is absent from the docs. I agree that @conradoplg’s “not building it” is a useful signal for both of us, but it still didn’t answer whether it belongs inside frostd or client-side, which is the actual scoping decision I was trying to get an answer to. I just put that exact question to them in a separate post.
This is awesome! If it’s okay, I’ll name you as an intended-user validator for that milestone. A pilot, rather than a rubber-stamp, is exactly what I want.
I have been leaning so heavily in that direction (I’m surprised I haven’t toppled over yet) for the very same reasoning. I guess convergent signals are useful, even if neither one of us is “authoritative”.
Cyze is a live example of the exact pproblem I have been scoping: do you run it yourself? Or do you hand someone a URL, with a disposable tunnel doing the sharing, and privacy the gap that’s left?
This is a great point. Baking one option into frostd’s source forces it on every consumer. And I believe dfferent consumers want different transports: e.g. Cyze wants Tailscale, aryaethn wants an onion service, someone else may want a plain tunnel.
Would you be interested in being a downstream beneficiary/validator for my project? If it takes that shape i could keep you in the loop.
The way CYZE is designed is that it’s a desktop app and from within the app multiple users can coordinate around a single user being marked as the coordinator. The coordinator in the app starts frostd and then has a choice to broadcast in different forms, using the standard method discussed in the CLI, spinning up a disposable cloudflare tunnel, and a future option im exploring will be for a Tailscale serve setup that a private group can use if they’re already connected to each other. Lastly, if someone hosts a frostd server through a public url they can just use that, but comes with being exposed to the web (frostd has a challenge built in to limit communications between participants in a group).
