> Your 16-digit account number is your login - anyone who has it can use your account, and it cannot be recovered if you lose it.
Can you explain the intent here? 16 digits seems to be nowhere near the threshold that's viable for any user authentication in 2026, especially given "Your own devices on one account can still talk to each other, like a small private LAN.".
> Acceptable use. We're logless and don't monitor what you do - but illegal or abusive use is not allowed and puts the whole shared service at risk. No spam, and zero tolerance for child sexual abuse material.
If you're not logging, how are you enforcing this? And relatedly, are you "logless" or do "traffic logs live in memory only and are scrubbed"?
> I plan to open-source the full stack as soon as I get feedback from real users, people like you
yeah the account number is basically the mullvad model, 16 digits, no email no password. its a tradeoff, i know some people hate it. login is rate limited server side so you cant just sit there hammering numbers at it. is it weaker than a long passphrase? probably yeah. the flip side is theres no personal info sitting in a database for someone to leak, or for someone to show up with a subpoena for.
on the local network point, thats only your own devices seeing each other. traffic between different customers is blocked.
logs, our thing is reactive, we're not sitting there watching everything. we act when we get an abuse report. some of it is just blocked structurally anyway, port 25 is closed so no spam is coming out of there. and we keep zero logs. child abuse material, account gets terminated if we get a credible report or a legal notice, but we dont proactively scan, thats not really possible when the traffic is encrypted and theres nothing logged to scan in the first place. the only thing counted is aggregate bytes per account for the quota and the trial. not what, not where.
and honestly, this is a one person project. code needs cleanup, secrets and config need to come out, and it needs a proper security pass before its safe to publish.
The difference is that Mullvad doesn't enable any east/west connectivity at all. If somebody guesses a user's Mullvad 16 digit number, they can use Mullvad's services as that user. If somebody gets a SmokeVPN users's 16 digit number, they can connect to that user's other devices.
How would you take any action with an abuse report and no logs? You'd get a report or subpoena or similar that listed an egress IP and a timestamp and say "We need information on this user for this charge" or "You're ordered to halt this illegal traffic", and you'd not have any way to tie that out to a specific user retroactively. There are plenty of providers who take the stance that they don't log and thus effectively cannot prevent or restrict illegal or abusive activity. I'm just not understanding how you could claim to both be logless and restrict those things.
My Mullvad comparison was focused on the credential, not on the LAN model. Brute forcing the account was never the issue, I missed the point about device-to-device was the real threat, fair point. I'm starting implementing LAN connections as opt-in, not default.
Second point, you're also right, because I was mixing prevent and identify, preventions shouldn't need logs, we can't take an IP address and a timestamp and attach a user to it, and the AUP imply something else, I'll rephrase this.
Some questions:
> Your 16-digit account number is your login - anyone who has it can use your account, and it cannot be recovered if you lose it.
Can you explain the intent here? 16 digits seems to be nowhere near the threshold that's viable for any user authentication in 2026, especially given "Your own devices on one account can still talk to each other, like a small private LAN.".
> Acceptable use. We're logless and don't monitor what you do - but illegal or abusive use is not allowed and puts the whole shared service at risk. No spam, and zero tolerance for child sexual abuse material.
If you're not logging, how are you enforcing this? And relatedly, are you "logless" or do "traffic logs live in memory only and are scrubbed"?
> I plan to open-source the full stack as soon as I get feedback from real users, people like you
Why wait?
yeah the account number is basically the mullvad model, 16 digits, no email no password. its a tradeoff, i know some people hate it. login is rate limited server side so you cant just sit there hammering numbers at it. is it weaker than a long passphrase? probably yeah. the flip side is theres no personal info sitting in a database for someone to leak, or for someone to show up with a subpoena for.
on the local network point, thats only your own devices seeing each other. traffic between different customers is blocked.
logs, our thing is reactive, we're not sitting there watching everything. we act when we get an abuse report. some of it is just blocked structurally anyway, port 25 is closed so no spam is coming out of there. and we keep zero logs. child abuse material, account gets terminated if we get a credible report or a legal notice, but we dont proactively scan, thats not really possible when the traffic is encrypted and theres nothing logged to scan in the first place. the only thing counted is aggregate bytes per account for the quota and the trial. not what, not where.
and honestly, this is a one person project. code needs cleanup, secrets and config need to come out, and it needs a proper security pass before its safe to publish.
The difference is that Mullvad doesn't enable any east/west connectivity at all. If somebody guesses a user's Mullvad 16 digit number, they can use Mullvad's services as that user. If somebody gets a SmokeVPN users's 16 digit number, they can connect to that user's other devices.
How would you take any action with an abuse report and no logs? You'd get a report or subpoena or similar that listed an egress IP and a timestamp and say "We need information on this user for this charge" or "You're ordered to halt this illegal traffic", and you'd not have any way to tie that out to a specific user retroactively. There are plenty of providers who take the stance that they don't log and thus effectively cannot prevent or restrict illegal or abusive activity. I'm just not understanding how you could claim to both be logless and restrict those things.
You're right on both counts.
My Mullvad comparison was focused on the credential, not on the LAN model. Brute forcing the account was never the issue, I missed the point about device-to-device was the real threat, fair point. I'm starting implementing LAN connections as opt-in, not default.
Second point, you're also right, because I was mixing prevent and identify, preventions shouldn't need logs, we can't take an IP address and a timestamp and attach a user to it, and the AUP imply something else, I'll rephrase this.
[dead]
I didn't mention on the original post, but the server currently has 84 exit servers in 45 countries.
[flagged]