I’m holding off on Fluxer until they decide how they’re going to implement federation
Seems wise. They seem competent in the front-end/client space and complete amateurs in the (difficult) protocol space. There is no example of successful tech (that I know of) that successfully added federation/P2P after the fact. It’s not an afterthought, it probably won’t ever happen.
Don’t do Element, Matrix is a nightmare (and a significant commitment) to self host. Other servers (recently, continuwuity) are a bit better on that front, but then you run into compatibility issues and edge cases as a forever second-tier citizen.
My advice is to just go with XMPP and ejabberd, and you will find clients for all kinds of usages and people (a free-er WhatsApp takes you to Conversations/Quicksy/Cheogram/Monocles/Monal, a better banquet/IRC-style rooms takes you to gajim/fluux, social networking and group calling takes you to Movim, etc).
Personally my needs are covered by Monocles on Android, Gajim on the PC, and Movim on occasions. Using multiple clients around the same protocol and account is a strength, not a weakness.
To add to the collection of chat apps enabling that, there is XMPP, too: https://f-droid.org/en/packages/de.monocles.chat/
I don’t think you know what a web app is.
I don’t think YOU do? A web app is an app built with web technologies and running in a browser. Which is also the case of Discord desktop (an electron app, i.e. Chrome).
Really? So I can message EA users with my MOVIM account? No? Well there’s a problem…
Again, you don’t seem to understand very much how any of this works. It’s pretty much the equivalent of saying “your devices at home are not using the tcp/ip protocol because I can’t ping your smart tv from the internet”. Actually, they do, but whoever operates the router (the XMPP server in this analogy) chose to make it this way. And yes, there is another way: for most of its history, GTalk was letting you connect to their XMPP server with the client of your choice, and talk to anyone else on the XMPP network besides accounts on @gmail.com. Federation is a built-in capability of the protocol that server admins may enable or not.
You can’t just label arguments you don’t like or agree with as “bad faith”. I have no motivation to hate on XMPP or promote Fluxer, other than liking one and disliking the other.
This is the extent of your argumentation:
it’s pretty clear by now that if you had any ability to comment meaningfully on this, you would have done it by now.
And importantly, my posts are a criticism of Fluxer. All I’m saying is “if you believe that you have the chops to develop a good client for a chat system, and you want it to eventually be self-hostable and federated, save yourself many years of suffering and do it on top of XMPP. Or at least if you don’t, take a good dive through it and come on the other side with a good story as to why your system is so much better. Showing mastery of the problem space will be free advertisement”.
I am talking about XMPP being almost 3 decades old
This is not the win you think it is.
It is not the win YOU think it is. So far you haven’t been able to cite a single specific issue with the protocol or universal flaws with clients. Get to terms with it: you are spreading FUD. Or make a real, substantiated case that supports your point.
Movim doesn’t even have a client at all, its just a PWA, which is a really poor experience.
Can’t wait until you realise discord is essentially the same thing :-) . Yup, it’s a web app. Always has.
You just come across as someone who doesn’t know much about the subject.
I don’t, and I shouldn’t need to. Good software doesn’t require vast amounts of research, you just use it.
People are using WhatsApp by the billions, which is essentially a stripped-down XMPP running on an ancient fork of ejabberd (there are many other examples of widespread use of XMPP: it props up your android notifications, it runs the nintendo switch network, EA/Riot games in-app chats are clients for it, etc).
But, nobody ever said that you need to research XMPP to use it. Only to have a sensible and articulated commentary in good faith. Which once again you fail at doing.
Then it’s even worse: if the goal is this, why give up on almost 3 decades of expertise solving that very problem?
I have no idea what you’re talking about.
I am talking about XMPP being almost 3 decades old and having gained a TON of experience and clever protocol design in the process. XMPP survived multiple generations of messaging apps (ICQ, AIM, Yahoo, MSN, Skype, GTalk, …)
In the way of usability. XMPP is actually a hodgepodge of different protocols sewn together and inconsistent across apps and servers.
Don’t believe all the disinformation you read online. XMPP is a IETF standard. It is extensible, and that’s the pragmatic take: in a federated environment, you can’t impose clients and servers to run identical versions, and so the protocol is versioned and contain fallbacks for all the major features. To help implementers cut through legacy extensions, there are compatibility suites that are revisited every few years or so. You will see that, the minute Fluxer goes self-hosted and federated (if ever), this clever extensibility will be dearly missed (we saw enough of that already with Matrix).
Moreover, XMPP has multiple independent client AND servers implementations, written in distinct languages. This guarantees that no actor can single-handedly take-over the ecosystem (a big risk with Fluxer, and many alternatives), and creates a fertile ground for innovation.
Fluxer has many many features that XMPP does not offer. If you’re familiar with Discord, you already know what those are.
If that’s so obvious, perhaps you could cite some? Did you even look into recent movim versions?
You cornered yourself into precisely NOT being able to invoke existing client shortcomings.
Again, no idea what you’re talking about.
You drove the discussion towards criticisms of the protocol, which is not the same thing as how clients implement it. In other words, you can’t simply say “XMPP sucks because this unmaintained client is ugly”.
No, because as I’ve already explained, XMPP is terrible.
XMPP deserves some fair criticism (like anything else having reached the real world and a substantial user-base), but that’s not one. You just come across as someone who doesn’t know much about the subject.
Then it’s even worse: if the goal is this, why give up on almost 3 decades of expertise solving that very problem? It’s a very complex one, believe it or not, and you can be sure that Fluxer won’t eyeball it in one shot, especially since federation is admittedly an afterthought and not baked in the design.
XMPP is terrible by comparison
In which way, exactly? You cornered yourself into precisely NOT being able to invoke existing client shortcomings. Protocol-wise, you would be surprised to learn how ubiquitous XMPP is even today, and for very good and practical reasons.
In all seriousness, Fluxer should just have been another XMPP client, purposely built for discord refugees. It would have gotten ahead faster by not reinventing a complex wheel, offered from the get go those characteristics (self hosting and federation) that are far-away roadmap items, and probably gained goodwill and many users in the process.
Time will tell, of course, but the internet history is riddled with failed messengers which bit more they could chew, the odds are not in Fluxer’s favour for one.
Another centralised system. By that simple definition, it will eventually turn against its users, like discord (or worse). Run away (ideally towards federated systems, XMPP with Movim is decent, and improving fast in areas that seem to matter to discord users, with EU funds, Matrix is another one)
It’s not as dramatic as GP makes it, but Matrix had been at the prototyping stage and at figuring out its core protocol and state resolution algorithm for more than a decade now, it’s pretty ridiculous in itself.
Isn’t that the premise of the “$4 ubuntu over droplet deployment” option?
Instead of having Secluso-Deploy ssh into some cloud box and prep it up with the server-side software, why not have a container deployment option as well? I get that you want to ensure that the server is publicly reachable for the mobile clients to work on the go, but ultimately (and in all honesty) at this point, that should be a user concern/choice (those more advanced users may be peculiar about running behind tailscale, a home-VPN, a port-routing config, …).
Needless to say, most people here might find it easier to work with containers and build trust in the project by having it run in an isolated environment with limited permissions than blindly trusting that the code is what it says it is and not quietly running a botnet at digitalocean with their PII attached.
I mean, unless you’ve got a hardware accelerator (which won’t be a thing before multiple years from AV2’s release, and possibly more due to its complexity), it will be measurably much worse than current codecs.
It doesn’t make any sense for large group chats: there’s just no secrecy to them. And that will cut you off from desired capabilities like server-side search. Not that I think that Zulip makes any sense in general when there are federated protocols that work and scale as well, but that’s another discussion.
I use my Trilium instance (notes-taking app, PKMS, …) for that kind of stuff: https://triliumnotes.org/
You can have a journal with day notes following a template with data-entry forms, which makes weight/mood/location/whatever tracker very easy to keep track of as a routine.
+1 on babybuddy, I’ve only good things to say about it and its community. Also, it’s a Django app, so the bar to tweak it exactly the way you want is very very low.
Since it’s a topic that comes back often on /c/selfhosted@lemmy.world I didn’t want to open new floodgates, but I can only warmly recommend https://triliumnotes.org/ :-)
ok, but there’s not much substance to your comment besides unsubstantiated “zealotry” towards obsidian and some general hot takes against lemmy and the FOSS community through which it emerged.
Maybe you could start listing out a few aspects and features of obsidian that you deem so important and unique, and I’m sure that you may discover a few very compelling alternatives.
As far as I’m concerned, I’m all set with https://triliumnotes.org/ . It’s not just a more versatile and capable note taking app, it’s also one that I can deploy simultaneously “local first” and “as a web service”, so my notes are reachable everywhere (even where I’m not allowed to install the heavy client).
Joplin is reasonably good as long as you don’t use so much metadata to keep things organised. It’s also pretty rigid, and hence limiting. If you want something with the superficial simplicity of joplin, but that would scale up to your needs, I recommend giving https://triliumnotes.org/ a good look.
If you drop the plaintext requirement (which IMO is anachronistic, if not for the necessity to fend against a potentially turning hostile developer in a close-source set-up), you may find https://triliumnotes.org/ liberating.
If you must stick to the “notes as plain text files” paradigm, siyuan is better than obsidian in about every aspect, and logseq in other, more niche ones. Trilium is better than them all (IMHO), being the only one that does “note as data” correctly and efficiently (you don’t have the same data model divide like seen in notion between notes and databases).
If you want notes “sometimes on the web, sometimes local first”, and possibly more than just notes (with the tools to extend into an actual knowledge base), you might be better served by https://triliumnotes.org/