pitninja

What you're describing is only possible on de-anonymized platforms that essentially have "know your customer" type policies where users have to provide some kind of proof of their identity. While I agree that there is value in social spaces where everyone generally knows the people they're interacting with are who they say they are, I don't think this is ever going to be feasible in a federated social platform. I think Facebook is the closest thing we have to what you're describing, to be honest, and I believe Meta has even kicked around having a more sandboxed Instagram for minors (though I don't use Instagram, so I'm not certain on the details there).

For me, in most cases on a platform like Lemmy, a person's age is not something I care about. I care about what people are sharing and saying. But then again, none of my interests for online discussion at this point in my life are really age centric. I think there are clearly better platforms than Lemmy if people want to guarantee they're only interacting within their age specific peer groups.

I stopped paying for YouTube the moment Google killed Google Play Music and forced YouTube Music on me. Now Google gets no money from me and Apple does because they still offer a true music library service.

I see, well I guess the real question is whether it can be improved at the server/protocol level and my answer is I don’t know. There’s some handshaking that clearly has to occur between your instance and the other instance to load the initial community state and I don’t know where that process can be optimized. I think I’ve seen people mention tools that have been created to automatically subscribe a dummy account on your instance to all the communities on the largest instances to kind of bootstrap the process for other users, but I don’t have a link to such a tool handy.

Edit, and there’s never going to be a guarantee that your server can talk to their server until you try clicking the link because the other server could be overloaded, down, or blocking your server.

What you’ve described is exactly how it’s supposed to work. Once a user has subscribed to an external community from your instance, it should load immediately for any users afterwards.

Personally, I think it’d be nice if you could self-host just the bridge instances and connect them with beeper yourself, so that the part that isn’t e2e encrypted is running on software you can validate and hardware you control.

I 100% agree this would be a great solution. That’s what I thought this page was going to be at first until I kept reading and realized it’s just a config guide for the Matrix Ansible setup. I wish they didn’t say “self host Beeper” on that page at all because self hosting Matrix has absolutely nothing to do with the Beeper service other than their devs built the bridges that they’re showing you how to set up with Matrix.

I’m not sure where this text is that you’re referring to.

It’s almost not even fair to say they’re merely contributing back to the upstream bridges. Most of the bridges would not exist at all without the Beeper developers.

It’s also kind of funny that the section of their website you quoted still has language that implies you have to pay for Beeper when it’s been free for months at this point. The primary reason to self host Matrix at this point is for privacy and complete control. And self hosting Matrix is only free if you use existing hardware and I would recommend a cloud instance for most people.

Beeper’s server set up is actually a lot more complicated than just standard Synapse at this point. When they say you can “self host Beeper” that’s really not accurate at this point at all. All of their 3rd party chat bridges are dynamically spun up on a per user basis with hungryserv and those servers operate in parallel with a synapse server for Matrix interoperability all behind a roomserv server. Here’s a presentation that one of their lead developers created regarding their new architecture.

Afaik, that isn’t in effect yet, but will become a major factor next year.

What do you mean by nefarious exactly? I don’t get the impression that it’s evil…

As long as they didn’t staple the wire or something.

E2EE only exists up to the bridge, not the whole way to your client

I just want to clarify that most bridges can be set up to have E2EE between the Matrix client and the bridge (regardless of whether the bridge supports encrypted chats on the bridged service because not all do, e.g. Facebook), but it is true that the bridge itself has to decrypt and translate between Matrix and the 3rd party chat service, so as you mentioned trusting who hosts bridges or doing it yourself is really important.

You can run headless or do what the person I was responding to recommended and put it behind an authenticated portal, but that’s not really going to stop other instances and clients from accessing the same resources that op is hoping to limit access to except in the most basic case of people casually browsing op’s Lemmy instance through op’s own lemmy-ui.

Edit, but to be clear, what I was responding to and my response didn’t directly address op’s specific concern (which I kind of misunderstood myself before just now rereading) that outside/guest users shouldn’t be able to search for communities from other instances and I think it’s a fair concern because just searching for a community from another instance brings in posts and could be a vector for spam/abuse.

Wouldn’t this do basically nothing to prevent a 3rd party client from browsing your instance without authentication? I don’t know that there’s much that can really be done about this because you need open APIs for other instances to be able to access the content of your instance in order to make federation possible. That said, it’s an important consideration that anybody running a single person instance should consider. If you run a single person instance, people can learn a lot about you just by seeing which communities are available on your instance. The only way to obfuscate your actual interests is to have a dummy account subscribe to all the top communities on the biggest instances. (Which, honestly, this isn’t a bad strategy to employ anyway if you’re wanting a fresh All feed).