What would your team need before standardising on this?

[shingrus]

A lot of the traffic here is clearly work traffic. Weekday volume runs about double the weekend, and the device mix skews Windows and Edge in a way consumer traffic doesn't.

What I don't know is what stops a team going from "one person occasionally uses this" to "this is the thing we use." Things I can guess at:

• an audit trail of who sent what — which the zero-knowledge design makes deliberately awkward
• self-hosting
• SSO
• a signed DPA or some compliance document
• retention controls
• a shared team view instead of per-browser history

If one of those is your blocker, just say which. If it's something not on that list, that's more useful still. I'd much rather hear "we can't use this because X" than hear nothing.

[edenworky]

Two thoughts, neither of which are a hard blocker for me:

I actually like that there's no SSO etc, but what could be nice is maybe a GPG and/or age and/or mTLS-style signing with cert signing requests, such that I can locally configure what I'm encrypting with in regards to what I'm sending, and what I'm decrypting with when I'm reading. That could be real fancy.

The second thing which is perhaps more pertinent and easier to solve is having a "receive-only" web app. For my use case, I have a private network, and I'm fine with anyone already connected to my private network being able to send stuff using 1time. Ideally, I'd even want to send "internal links" which are only resolveable given a network connection, and "external links" which are available publicly; but for right now I need external links, which means I want my links to be publicly receivable, but only for internal connections to be able to create links and (heaven forbid) upload files.

Currently I was thinking of having two web instances with the same backend, one for an internal domain and one for a public one, and just block everything except as strictly necessary for receiving files for any external connections at the reverse-proxy level. I'll start with just the partially-public-facing web instance, which I'm fairly confident I can do, but it might be a compelling use case if addressed. I.e., access-by-network, rather than by account. (Well, unrelated really, SSO is orthogonal to this)

[shingrus]

Thanks for writing this up.

GPG/age/mTLS is probably not happening, at least not soon. The blocker is that it'd only really work in the CLI. Browsers don't have a keyring and I'm not going to ship OpenPGP.js (page weight is already tight), so you'd end up with links the web app can't open, and "recipient needs nothing installed" is more or less the whole point of the site. Signing runs into a similar wall: to check a signature you need the sender's key ahead of time, and that's basically the account system you said you're happy we skip.

Receive-only I like though, and I'd take a PR for it.

The proxy side you've obviously got covered. What a proxy can't do is fix the HTML. /v/ and /f/ have hardcoded links back to the create pages, so on the public instance every button hits a 403. That's the part worth putting upstream: a flag so the read pages stop assuming the send side exists. There's already a similar one (isBlogEnabled) you can copy the shape from.

One thing worth knowing before you start: it ends up being two builds, not one. Astro prerenders everything, so a single build can't show the CTA internally and hide it externally.

The bit I haven't worked out is whether per-instance is enough, or if you really need the internal/external scope per link. That second one means storing a field and checking it on read, which is a lot more than a build flag. Mind opening an issue first so we can settle that before you spend time on code?