I agree that it should be easier. The problem comes from the element mobile apps migrating to a new registration flow that homeservers other than synapse haven’t finished implementing yet.

If you use continuwuity, and it’s few users, you could create users via the admin room. Then login should work. Still, annoying workaround.

And yeah, setting up LiveKit is a bit annoying. Maybe someone’ll make a compose flow that combines all of them, but I am too lazy rn, and I haven’t seen any from anyone else yet.

I seem to remember that you can sign in, but not register, with Element X and continuwuity. Should be fine with web/desktop clients.

No, the red flag is being ‘self-hostable’, but trying to concentrate all your users in a central, non-federated, monetised instance.

Also, we cannot verify how long they where in development because they squashed their git commits. There’s usually no good reason to do that.

I host two homeserver, one on synapse and one on continuwuity, both pretty small (tens of users), but with users in lots of large rooms. The second one was significantly easier to set up, and uses a lot less resources.

Also, element and element X work, but aren’t great. It depends on the user, of course, but I don’t think you get people by giving them the ‘dumbed down’ version.

Isn’t fluxer partially LLM-coded according to the dev?

LLMs are stateless. The model itself stays the same. Doesn’t mean they’re not saving the data elsewhere, but the LLM does not retain interactions.

The bigger issue is that reports currently don’t federate. A report will always go to the admin of your homeserver (which might be you) not the admin of the homeserver the room you’re in is on, nor the admin of the homeserver of the other users.

Most larger (1-2k people) communities get around that by just having you ping the mods in reply to the offending content, which is a band-aid.

A spec for federated reports is apparently being worked on, but not yet available.

A discord server-like would be a space, containing channel-like rooms. The main difference is that rooms can also exist independent of spaces, if you just need a single chat for some people instrad of a group of chats.

You can set permissions for a whole space, it’s just that they currently work differently than Discord. Members have a power level, and you set the power level from which each function is available. So, e.g. Sending messages from Pl 0 (representing normal users), banning users from PL 50 (representing moderators), changing server settings from level 100 (representing administrators).

It sounds complicated, but once you get used to it it’s pretty easy.

Matrix is not

With LiveKit for calls / screen share, it is for my group. Though I’m not saying it doesn’t have issues.

will never be

Community-developed homeservers like continuwuity have gotten a lot of new support on the last few weeks. Clients like cinny are getting pretty close to a replacement ux wise (if you look at PR2599 on Cinny’s GitHub, they are working on and will soon merge support for LiveKit in a way that is very close to voice channels).

I also generally think that the only way to replace Discord as an ecosystem where you talk to many people from different communities is a federated protocol, not a bunch of new silos, one for each community.

I had a brother laser printer with a pre-heating roll that went bad. Sourcing a replacement for that was pretty annoying. But I get your point.

“I have helped pay for something good. More people could benefit from it, at no additional cost to me. But I’d rather they not.”

See my reply to the other comment.

I really do believe that the most sensible way to formalise it is just requiring publically funded code to be open source. Requires less complexity than co-op, and works out the same if enough countries opt-in.

See this as an example:

https://github.com/Governikus/AusweisApp/

https://commission.europa.eu/about/departments-and-executive-agencies/digital-services/open-source-strategy-history/european-union-public-licence_en

And the UK taxpayer might save money by using open source projects funded by other municipality in different countries. This is already the standard for some EU projects.

Could some countries ‘freeload’? Sure. But what’s the actual cost for that? The people in those places getting better software, while the original users are no worse off?

Could also help with less wealthy countries having access to software they couldn’t otherwise afford to develop.

That might not be practical. But everything else done with public money should be open source. A lot of these software projects are more or less necessary for every city globally. Collaborating on a few apps and programmes is a lot more sensible then everyone having an app custom build by a contractor.

I use qemu/kvm with vm manager. There’s a lot of other options too. Most of them are valid indefinitely.

I use the Win11 LTSC IoT Enterprise Image, because it cuts out most of the usual windows bloat. Maybe have a look at massgrave.dev.

Honestly, I’d give the cool gadgets to China.

You can hand over a USB device fully to a Windows VM. That’s how I update my Yamaha stuff.

… sure. Nothing here is wrong, but there’s ways to try and mitigate that. And then it’s kinda an arms race, and vigilance.

Good as a general recommendation.

I also feel like the risk levels are very different. If it’s something that performs a function but doesn’t save/serve any custom data (e.g. bentopdf), that’s a lot easier to decide to do than something complicate like Jellyfin.

I do have public addresses for Matrix, overleaf, AppFlowy, immich because they would be much less useful otherwise. Haven’t had any problems yet, but wouldn’t necessarily recommend it to others.

I’d never host any stuff with “Linux ISOs” on a public adress, that seems like it’d be looking for trouble.

Yes. Strip searches suck. This is about publically sexualising people against their will. That also sucks.

And some people seem to be hell-bent to put much more scrutiny on the person being sexualised than on the person sexualising them.