exceptione

  > At 10% of regular price it is a steal so far.

Here standard plan has been discounted to $18.00, from $25.00/month.

I stand corrected then. Although I had checked the website and the sparse UX details on the website only showed images of plain text. So this is an opportunity for the Briar people if they still feel the energy.

TIL Briar is text-only, per https://eylenburg.github.io/im_comparison.htm

  «The Yivi app is the successor to the IRMA app, the first privacy-friendly digital wallet based on personal attributes. IRMA (renamed to Yivi) was developed by Bart Jacobs with his team at Radboud University in Nijmegen. Jacobs is also chairman of the Privacy by Design Foundation. In 2019, collaboration with SIDN began, with SIDN taking over responsibility for managing IRMA’s backbone, to ensure the technology’s essential continuity and availability. Since the fall of 2024 the Dutch company Caesar Groep takes over from SIDN the further development and management of Yivi, in close cooperation with the Privacy by Design Foundation.»

Thanks for following up. I don't understand why your post has been flagged.

Sounds to good to be true, but it works for the given examples! What is the scope though? It produces garbage with larger documents with tables and figures. For example this large document, even with removed menu and headings: https://docs.redhat.com/en/documentation/red_hat_enterprise_...

Could it be it has only been fed small documents?

  > I don't think pointers (beyond a simple "same as in previous row" marker) will be a huge improvement, since you still get a multiplicative number of rows

  SELECT BlogPost bp LEFT JOIN Comment c WHERE bp.id=101 AND c.blogPostId=bp.id

Compression and decompression takes CPU-time, I have a hunch this brings in an unacceptable penalty. At least this route hasn't been chosen while it would be the easiest to implement.

  > You'd still return a multiplicative amount of rows, even if those rows contained only a reference

  >  `array_agg` in postgres avoids this

EF Core documentation disagrees though: https://learn.microsoft.com/en-us/ef/core/querying/single-sp...

Correct. However, this imho does not need to be a problem when using references to data instead of data duplication when sending results over the wire.

Databases are incredibly smart when it comes to fetching related data, a single select is indeed better than splitting queries and doing multiple roundtrips.

The problem however is in how results are returned over the wire. Duplicating rows is needless, but seems to be still the standard.

Couldn't we make references as `byte offsets in the result set` work to handle duplication? Real memory pointers wouldn't work over the network of course, but if the database driver would return results like this, the client could easily stitch these together. My hunch is that even if we implement references on a higher level than raw byte offsets it would still be more performant than just returning R1*R2 bytes for any R1<1:N>R2.

---

EDIT: According to LLM friends you could achieve before wire de-duplication by using FOR JSON AUTO in SQL Server or jsonb_agg in PostgreSQL. Not sure how much overhead that incurs though.

I don't understand the argument why `AsSplitQuery` could be more performant than a single round trip involving a multi join query. People mention data duplication and increased memory usage, but I would assume that `duplication` is just a matter of an extra pointer, not a bit-for-bit duplication of every reference to a single row.

Please enlighten me.

  > Intent understanding: GPT-5.6 can better infer the user’s underlying goal and intended level of work without you specifying every step. Continue to state important constraints, approval boundaries, and success criteria explicitly.

Canals were used for transport by boats/ships. My guess would be that railings would be a hindrance for loading/unloading.

thx!

Thanks, that would indeed be helpful.

  > (It's marijn, not merijn.)

For people who have dealt with react, this part might give some insight into that topic (https://wordgard.net/docs/prosemirror/#h-transactions-and-ch...)? Nevertheless, it would be good if this could be addressed in the docs.

I am not sure if this makes things easier for react interop, but this piece might be of interest too:

  > One of the biggest mistake blunders in ProseMirror is that the editor view does not get access to the transaction objects when updating, just the state. Wordgard does not repeat this mistake, and makes updates take transactions, not just a new state.

  > This means that things like the DOM update logic and UI plugins can precisely observe what happened, and handle changes in a efficient and more effective way. The weird unexpected DOM redraws that are still a thing in ProseMirror should not occur. Only the precise DOM structure affected by the new transactions will be updated.

I think most people would love to the know the 'why'. This page discusses differences with prosemirror and is the closest I got to that question: (https://wordgard.net/docs/prosemirror/).

One thing to note is that there is not an upgrade path. Many concepts are shared with prosemirror, but it seems that switching means doing quite some work (correct me if I am wrong). Obsidian is based on Code Mirror so I guess they won't be switching, but tiptap.dev and others do.

@marijn, maybe you could address why wordgard is worth the switching cost?

EDIT: I see many points are addressed in Marijn's personal blog. I submitted (https://marijnhaverbeke.nl/blog/wordgard-0.1.html) to HN for better context.

Possibly, but I think what we wish for is a language with a nominal type system that lets you switch to structural typing when needed.

Luckily, F# has type providers, which lets the compiler construct nominal types based on the structure of real data (like json, xml or any format you want), saving you from the effort of building wrapper types by hand.

Yeah, in your example the structure is sufficiently dissimilar to a string for TypeScript not to confuse them for each other. However, if you also have an identity provider returning UserInfo objects in the form of {'domain':'example.com', 'user':'john-doe'}, you might not like it that now any email address is a valid UserInfo object. On the type level in TS, you cannot tell those types apart. But I guess you figured that out already.

Javascript doesn't have structs. The idea is that you have data on one hand and you have type witness about that data on the other hand. Type witness is something for the type system. But here you encounter the limits of structural typing versus nominal typing, because structural typing isn't able to witness that directly.

In sufficiently strong nominal type systems, I can hide the constructor for an EmailAddress type (as in: nobody can just construct an EmailAddress type). In Haskell speak, I can then export a function parseEmailAddress = rawString :: string -> EmailAddress. The function parseEmailAddress is the only place that has access to the constructor. Which means that the only way to turn a string into an EmailAddress is by calling parseEmailAddress.

Note that at runtime EmailAddress is just a string. The boundaries live in the type system, not on the value level. A structural typing system (as in TypeScript) does not enable that, it forces you to turn EmailAddress into something else than just a string.

Are you confusing Email vs EmailAddress? I think that in many cases people would prefer EmailAddress to be represented as a dumb string at runtime. But if you don't, you will easily find other examples where you have 2 structurally similar types, that you don't want to mix up.

It is nice the author mentioned F#, because if you want to target the browser (or any JavaScript runtime), you can do from F# directly from fable (https://fable.io). This allows you to program by default in a type safe manner without having to play tricks to circumvent the limits of structural typing.

I think your friend might have used portableapps.com, they offer many types of browsers . These programs are packaged to install under a restricted account, without requiring admin rights.

The logical conclusion is to shutdown Meta, Youtube, TikTok, Twitter to name the biggest offenders. And why on earth would algorithmic manipulation, brain washing and exploitation of adults be allowed via the same platforms?

I am not disagreeing with you, but the conversation to be had is far, far wider than "think of the children!". Part of any deal would have to be: privacy of citizens is not a business model. But then you are facing the full might of Corp Inc, including their legislative powers.

Possibly stupid question after skimming: libvirt provides a plethora of networking options, but some networking types require a physical ethernet adapter, so you are out of luck when you have wifi only. Would this make it possible to present libvirt an ethernet adapter that is actually backed by wifi?

Why do you think they don't want to do it? I find that a weird statement, and your given reasons don't make sense to me. This is one of their core programs, and as part of that have taken over some IP via espionage programs. China is actively trying to build one for quite some time now.

  > people overstate complexity of ASmL machines. They are not impossible to make or use, specialist work sure but its possible. The only reason why no one does it is: 1) IP laws, 2) Costs

The real reasons are: enormous complexity, lots of original research involved, deeply specialized supply chains. Recreating that takes lots of time and money. Even if you cut corners and steal IP. So that leaves China with 'time' as the real impediment. And who knows, AI will be a boost to get to that goal?

I thought the time frame of 10 years is the most recent forecast.

The comparison with cars and cellphones falls short for ASML machines. The former categories involved western companies transferring IP to Chinese counterparts. So far, the Chinese have succeeded in stealing IP from ASML, but this is complexity in its own category. Also, the whole supply chain is part of the solution. That is a lot to copy.

But I agree that, given enough time, China should be able to. But Volvo en Tesla handing over IP themselves, and phone makers letting China produce and assemble phones (maybe not as extensive these days anymore) is something different.

EDIT: I mentioned Saab when I meant Volvo. Not sure if people downvoted based on that, I have no info on Saab so consider that as a mistake.

  > If you visit a website you should ... see the website. See its content. Be able to read the article whose page you are attempting to visit. Showing a “subscribe to our newsletter” or “accept our fucking cookies” dickover to someone trying to read an article on the web makes no more sense than sending out an email newsletter that only contains a link to read the newsletter on a webpage. A webpage should show the webpage. An email should show the email. I should not have to explain this.

I hope so. I would love if search engines would do that.