How so? Trilium is a web app, that you may use wrapped in an electron shell. Or not. Up to you.
What do you mean "half-assed"? I manage very large collections of notes with it, in ways that no other PKMS can, just because none of them approach "note as data" (or "typed notes") in a way that Trilium does.
My #1 criteria is for all my notes to remain consistent over time. If I create a note type for "Projects", I want all notes representing a Project to have the same properties (start date, location, cost, ...) at all time. Trilium has very neat concepts like Templates and Attributes Inheritance that make changes on the template be reflected on instances. That's something even AnyType, Notion, Capacities, Logseq, Tena and others are struggling with. When your collection grows, so does your bookkeeping with those systems, and what should be a tool to help you get stuff done ends up giving you more work to do and holding you back. I beg to see a tool that helps my productivity so much.
You can see by yourself at https://triliumnotes.org/
It's FOSS, it's web so you can use it hosted, or local first as an electron app, or both and then they will sync together.
It is NOT a UI for a folder of markdown files, because that's silly when you expect from your system to hold relationships, metadata, rich note types, notes to coexist in multiple places, etc. Since it's FOSS, and since you can sync your notes real-time and distributed across machines, there's nothing wrong with this.
You can use the web version on Android as a PWA, but it won't sync offline. There are workarounds to run a local server on your device for that use cases (not ideal in terms of user-friendlyness, but gets the job done).
You don't need to pay anything to anyone if you host it yourself or if you keep it local. There is no official hosted plan, some people offer to do that for a tiny fee at https://www.pikapods.com/ (never used them, some people say they are decent).
Can trillium store all files in markdown/plaintext?
Content is stored in a SQLite db (with options to export to markdown & al.), Trilium is open source, so there's no lock-in and you get the best of both worlds.
How is the theming by trillium? I use a light tan interface because it is much easier on my eyes, personally than high contrast white or eye-straining dark themes.
You can totally reimplement the whole UI if that's your thing, everything (or close-enough) is a note in Trilium, including themes and other JS/CSS notes that will override or extend parts of the application, like add-ons would elsewhere.
This had me have a look at commet, gosh is it bad. On desktop it's unbearably slow. On Android it crashed as soon as it had to display a notification. We are still very far from a healthy Matrix ecosystem of independent client/server implementations.
Have a look at Trilium. Anything Obsidian can do, it does better. And syncing is native.
Donate to Matrix now that they have spent tens of millions with nothing to show for them, and got cut loose from their investors as a consequence. Sure. Whatever to keep the grift going.
I mean, if you want Matrix AND that it works, you just install ejabberd or prosody and go on with your life. But then there's nothing fancy to report or brag about, it just works.
Some thoughts from "Asahi Lina" that sums it up: https://phanpy.social/#/vt.social/s/116054925440220855
You simply can't have your E2EE cake and eat it too. Sorry.
At the end of the day, decentralization (with data portability) is more valuable than E2EE if your concern is data mining. That can be done without all the major issues of E2EE.
The specification only seems to say that message content are encrypted, making no mention of encrypting any other data than message content.
Correct, what's not encrypted are things like typing notifications, read markers, recipients. Which was my whole point: this is inferred easily by the server anyway: it hosts your account and your contacts list already, it routes your messages to recipients and across the whole network. You can't really operate without this level of trust. Neither in XMPP nor in Signal.
Also, just because you self host it doesn’t make the unencrypted (meta)data any less dangerous.
You seem to hold a very naive take on all of this. This is the basis of federation. In a centralised system (Signal), everyone must trust that the one provider to act (and keeps acting) in good faith. Federation loosens this by having you trust a provider of your choice, and by giving you the ability to move on otherwise. Zero-trust is only theoretically achievable with peer-to-peer, but we have yet to come-up with a system that is performant and efficient enough at scale to be deemed usable. P2P networks often resort to edge gateways to do some caching or connection brokering, and at that point you are back to the same tradeoffs as with federation, only with more steps and worse results.
That just makes your server the point of failure.
Always was, always will be. Like I said, remove the server and you are onto something… Make it work well, and you will be the first, and do the world a great service.
By your logic, why encrypt at all?
E2EE is one mitigation against one type of threat. Not a silver bullet.
OMEMO leaks plenty of metadata
Could you even cite an example of such leaked metadata? I'd like to also remind you that metadata leaking to your own server (which you can chose, which you can self-host) isn't as big a deal in XMPP as it is with other services. Which is also why I can't take Soatok's opinion about and obsession for Signal seriously: when all accounts are hosted by a single actor, you have a much bigger metadata problem, and all obfuscation attempts (sealed senders being one) are ultimately defeated by simple timing and packet correlation attacks.
I spent 40 min scouring Snikkets website and source repo without any clear way to determine what version of OMEMO they bundle.
You were probably looking at a rebrand/spin of https://xmpp.org/software/conversations/ . All major XMPP clients and servers declare their compat via DOAP: https://xmpp.org/extensions/xep-0453.html
My point is that security is independent of adoption.
Correct, but in this case OMEMO is secure and is used in contexts where security actually matters. There have been multiple audits of it over the years:
view more: next ›
Oh, so your experience with Trilium is at least a year old. In the meantime the original dev popped out of their hiatus to formally hand over the project (and the rights over the original repository) to the newly formed community, which has been very active (porting to typescript, internationalisation, porting of the UI to reactive components, full rewrite of the UI, new collections feature, new note types, new doc, new homepage, some LLM APIs, etc).
It's still an opensource project run by volunteers on a best-effort basis, but it punches way above its weight-class.