> And sure, you can form an Estonian company. But then you have to try and fly under the radar with regards to the 'permanent establishment' rules.
It depends on what you’re trying to achieve. If you want to do some tax optimization shenanigans, then yeah, don’t think it’ll work for you (if you’re in the EU, at least). But if you just want to set up a small to mid-sized company without dealing with German bureaucracy, I think Estonia is your best bet right now. I don’t think (IANAL) you would get into trouble for having a permanent establishment – you’ll just have to still deal with the DE tax office. But if EU-INC really can unify the processes for all countries, I’m all for it!
> The whole process is so clearly setup to discourage people from actually forming companies.
By the way, it’s really backwards in Estonia. I’ve seen zero sole proprietors when I was living there – everybody just opens an LLC.
This. In Russia, employees of all sorts of organisations are “encouraged” to vote for a particular candidate or party (not always the ruling party, though it doesn’t really matter for different reasons I won’t get into).
As far as I know, these votes have gone mostly unchecked before electronic voting, but after that, they’ve started voting straight from the workplace computers. There were, of course, a lot of straight-up falsifications as well.
That said, our pen-on-paper voting isn’t too legit either :’)
I don’t think it works for curl though. You would guess that sloperators would figure out that their reports aren’t going through with curl specifically (because, well, people are actually looking into them and can call bullshit), and move on.
For some reason they either didn’t notice (e.g. there’s just too many people trying to get in on it), or did notice, but decided they don’t care. Deposit should help here: companies probably will not do it, so when you see a project requires a deposit, you’ll probably stop and think about it.
> I don't like the idea of having a partner or co-founder because I have put in 100% effort while others might not contribute equally.
I get it – I’ve felt the same when I was looking for a cofounder too. It’s tricky to find a person that’s passionate about the same thing as you are. But I think it’s still worth it to be looking for one.
Of course, you can also hire a marketing guy, or just ask around to see if you can barter (e.g. help them with something IT instead). But I think having a cofounder is still great for motivation – if you do find the right person, that is.
It’s interesting, Lawnchair works totally fine with these “app action” 1×1 widgets, and Firefox can add website shortcuts without any problem for me. I’ll try it in Brave a bit later.
This loop handles cases like `eggtools._spam` → `eggtools-spam`, which is probably rare (I guess it’s for packages that export namespaced modules, and you probably don’t want to export _private modules; sorry in advance for non-pythonic terminology). Having more than two separator characters in a row is even more unusual.
Keybase's Merkle approach is elegant for their use case (efficient proofs without revealing the full chain), but I went simpler with a linear chain because:
1. Audit trails are inherently sequential - they're ordered by time and typically read/written in order. Merkle trees shine for unordered data where you need efficient inclusion proofs.
2. Verification simplicity - with a linear chain, integrity verification is just "walk the sequence and check that each entry's previous_hash matches the prior entry's checksum." O(n) and dead simple.
3. Storage efficiency - each entry stores two SHA-256 hashes as strings. No tree overhead.
4. Regulatory fit - for GxP/CFR Part 11 compliance, the requirement is tamper detection, not zero-knowledge proofs. A linear chain detects any modification equally well.
That said, if I ever need selective verification (prove entry #500 is valid without transmitting the full chain), I'd revisit Merkle. The implementation is in src/snackbase/infrastructure/persistence/repositories/audit_log_repository.py if you're curious.
On the custom DSL:
This was the biggest architectural decision in SnackBase. Here's the honest breakdown:
Why not just use existing options?
>Approach: Python eval()
>>Why I didn't choose it: Security nightmare - can't safely let users store arbitrary code in the database
>Approach: CEL (Google's Common Expression Language)
>>Why I didn't choose it: Battle-tested, but heavy dependency and less control over semantics
>Approach: JEXL/JSONLogic
>>Why I didn't choose it: Another runtime to learn, harder to integrate with my macro system
>Approach: Pure JSON rules
>>Why I didn't choose it: Becomes unreadable for complex expressions
What drove the decision:
1. Permissions are database-storable - rules live as strings in the permissions table, editable via API and admin UI. I needed something safe to parse and evaluate at runtime.
2. Sandboxed execution - the DSL only exposes specific operations (==, in, @has_role(), etc.). No imports, no file access, no arbitrary code. Even if someone compromises the admin UI, they can only express logic within the vocabulary I provide.
3. Syntax for non-programmers - "@has_role('admin') and @owns_record()" is more approachable than Python lambdas when you're building permissions in a web UI.
4. Macro integration - the @ prefix ties into my SQL macro system, letting users define reusable business logic like @is_department_head() that executes database queries.
The trade-off:
It's 700+ lines of lexer/parser/evaluator code I have to maintain. Every edge case (null handling, type coercion, short-circuit evaluation) needs explicit test coverage. Debugging a failed rule means returning syntax errors at position X rather than a stack trace.
If I were starting fresh today, I'd give CEL harder consideration. But since permissions are a core differentiator for SnackBase, having full control over the semantics has been worth it—especially for field-level access control and the wildcard collection system.
Implementation files if you're interested in it:
- src/snackbase/core/rules/lexer.py - tokenizer
- src/snackbase/core/rules/parser.py - recursive descent → AST
- src/snackbase/core/rules/evaluator.py - async evaluation with short-circuiting
Hmm, I guess I did Keybase a disservice. They do use a chain per user, and also store each leaf in a global Merkle tree, and then also store new Merkle tree root hash in a blockchain (previously Bitcoin, currently Stellar).
Although I think there are ways to make Merkle trees append-only (see e.g. the Certificate Transparency protocol [1]). This should be a suitable audit log implementation, even if a bit more tricky. That said, it is probably an overkill for most scenarios!
As for the DSL, I think I’m more interested in the specific usecases for changing the rules in the runtime, considering that you have to change the code to e.g. add a new endpoint. Is it perhaps a common thing to tweak for each tenant or something?
Personally, I’m considering pgfga [2] for my next project, though the rules will probably live in the codebase for now :-)
It depends on what you’re trying to achieve. If you want to do some tax optimization shenanigans, then yeah, don’t think it’ll work for you (if you’re in the EU, at least). But if you just want to set up a small to mid-sized company without dealing with German bureaucracy, I think Estonia is your best bet right now. I don’t think (IANAL) you would get into trouble for having a permanent establishment – you’ll just have to still deal with the DE tax office. But if EU-INC really can unify the processes for all countries, I’m all for it!
> The whole process is so clearly setup to discourage people from actually forming companies.
By the way, it’s really backwards in Estonia. I’ve seen zero sole proprietors when I was living there – everybody just opens an LLC.
reply