Please, please - just link to the actual "CUE" project. Not everyone has heard of your favourite thing. The first reference to `CUE` should be a hyperlink.
For other people: I'm pretty sure the author is talking about https://cuelang.org/
This is not to make the general claim "Typing is a hindrance in parsing applications", or anything close. It's saying "the current static type system(s) available in Python would have made this Python library much worse".
This might be because of really old data and old code that saved it. But changing this decision is very hard, so I imagine many systems that adopted escape-on-input once are stuck with it.
This is nice. With variable fonts, some of these fonts now are slightly under-represented - for example "Recursive" is really a large family, the website shows just one extreme point of a large multi-dimensional space.
I'm currently enjoying using the "Recursive Mono Semicasual" variant of Recursive - https://www.recursive.design/ . It adds just a little bit more fun that a typical mono font, especially at higher font sizes (e.g. for headings in Markdown in an editor).
The default user model is fine, but I *always* start a project by extending it, for future-proofing. If you need to add to it, this is *so* much better than having to add a one-to-one, and at *some* point down the line you find you do want to add something. The problem is that doing it later when you need it is a pain, because of poor support by the migrations framework.
It's like 4 lines of code that saves you so much grief later on:
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
pass
AUTH_USER_MODEL = "myapp.User"
If you never need it, those 3 lines are not hurting you. In terms of a default, I think it probably would be nicer if Django pushed you to do this up front.
I agree 100%. Even if you don't need it, these lines don't hurt you, but most of the time, the additional model is put to good use. I usually add metadata, such as additional timestamps, flags, tags, custom user settings, consent or preferences.
I find it very strange to have claims about the database being tamper-evident etc without a clear description of the threat/trust model, and how/for whom it works. For example, what data does the client need to store to be sure no tampering has occurred?
I agree 100% with the need for the threat model. I think the current system is, at-best, a system with a tamper-evident audit log. Which, could still be interesting, but the authors' use of ill-defined terms makes it easy for people to think their software does something that it's not.
What's supposed to happen is that the server will give the client a path in a https://en.wikipedia.org/wiki/Merkle_tree to the current state, the prove that the key-value pair is included in the Merkle tree.
There are, however, some subtle issues which can arise if you're not careful. In particular, what happens if I set the key k to value v1, and then set the key k to value v2? If I subsequently ask for the value of k, I ought to see v2, and a proof that k is v1 shouldn't check out. However, in order for this to work, it's not sufficient for the server to prove that (k, v) is in the audit log, since that would allow for the server to maliciously roll-back the state. What you really want to prove is that v is not just _a_ value that k was set to, but _the most recent value_.
It's unclear to me whether the code actually does this--there's no architecture guide which describes the cryptographic algorithms at play (or what the threat model is), and the code appears to be mostly devoid of comments. There is a reference to separate inclusion and consistency proofs, which might be this distinction. But it's really hard to tell from the digging that I've done.
This is a very interesting point. Rollbacks are protected by consistency proofs and with inclusion proofs it's possible to detect such situation but it may require scanning over the transactions. immudb does not only provide access by key or key prefixes but it's also possible to fetch a particular tx by its unique identifier or scan over them.
For sure it's not the optimal solution, some ideas to cover this scenario were discussed but not yet fully defined.
I'll find detailed information in the research paper: https://immudb.io/
Basically a hash value denotes the entire state of the database (including the entire history). This hash may be cryptographically signed and exported from the server.
immudb SDKs keeps track of the last verified state, each time a new one is received, it's cryptographically validated.
Whenever a particular entry or transaction is verified, the latest validated hash also used. If the entry was tampered in, hashes won't match.
I'd have a look at the research paper, if it weren't hidden behind an e-mail wall. I was initially happy to see a 'research paper' link at all, but that e-mail wall definitely compromises my first impression of immudb, because now it looks like I'll be getting a corporate brochure and not an actual technical paper.
> Basically a hash value denotes the entire state of the database (including the entire history). This hash may be cryptographically signed and exported from the server. immudb SDKs keeps track of the last verified state, each time a new one is received, it's cryptographically validated.
Okay, but how do you persist that hash across eg. client restarts? You obviously can't store it in the database. And this does not sound like "zero trust" to me - that's a much higher bar to meet, and would allow for eg. untrusted writers.
As I understand it right now, immudb works more or less the same way that Git does; it's a DAG of database (instead of file) mutations, and you can persist the latest commit hash to ensure that someone hasn't messed with what a branch points to.
Which can be useful, don't get me wrong, but it's not "zero trust" and it's certainly a fairly niche security feature.
Edit: To be clear, I'm very much in favour of what immudb seem to be trying to do - getting enterprises away from ultimately dysfunctional "blockchains" by providing something more sound with nominally the same features/appeal. But it's always important to be very clear about what your tech does or doesn't provide, blockchain or not.
first of all, thanks for your feedback and discussion :)
if entering an email for downloading the paper is a concern, we'll consider it.
immudb should be used as a traditional database (log, key-value or even a relational store - with limitations of course), so it's up to your deployment to whom you give user credentials with read/write permissions. The key difference is the state being captured by a single hash value.
Given the hash value denoting the entire state can be signed and exported. It's out of control of the server how many copies or when a validation is going to be made. Currently, official SDKs are storing the latest validated hash in a local file, but it's perfectly possible to store the hash in a remote storage, other database, etc. This will ensure data is only added but never changed once written, please note with never changed I mean it's subject to detection when a proof is requested.
immudb does not pretend to provide a complete security solution, but a key component when you deal with sensitive data.
I think the case for server-side HTML rendering has never been stronger, and of all Django projects I work on, the ones I enjoy most are those that never got on the SPA bandwagon. From both a developer and user point of view I find them much faster and less painful. There are many cases where you really, really don't need the massive amount of extra complexity involved in designing APIs, adding JS frameworks etc.
When you need a bit of extra UI goodness, htmx https://htmx.org/ is a fantastic solution, and you can still use SPA-type approaches for things that need them.
You can also benefit from massively faster (and more reliable) functional testing when you are mostly standard HTML - see django-functest https://github.com/django-functest/django-functest/ for an example of this.
I found Martin Fowler's "Technical Debt Quadrant" helpful on this - https://martinfowler.com/bliki/TechnicalDebtQuadrant.html . He argues you can have deliberate and inadvertent debt, both of which can be wise or unwise - the debt metaphor still works.
Also, xmag, you already have it installed if you use the X Window System. It's 41kb, extremely lightweight (always starts instantly) and also magnifies a screen portion which is helpful for picking colours.
> you already have it installed if you use the X Window System
Maybe.
It looks like it's been spun out into `x11-apps` on debian based distros in the last year or two, and for some reason I don't have that package installed despite using X
For other people: I'm pretty sure the author is talking about https://cuelang.org/
reply