• 0 Posts
  • 22 Comments
Joined 2 years ago
cake
Cake day: June 15th, 2023

help-circle


  • PieFed is a completely different codebase than Lemmy, but that is aiming for the same paradigm and uses compatible federation so they’re cross compatible.

    So it’s basically another option for people running instances to pick running a PieFed instance over a Lemmy instance.

    That having been said, I heard they built some features Lemmy doesn’t have that people like. Like I think I heard it groups the same link posted to multiple communities so you can see a more overall sense of the discussion? Or something? I haven’t used it…




  • Maybe I should create a new post for this but has there ever been discussions regarding SSO? So you have one identity across all fediverse services?

    This comes up from time to time, but usually not for what you want. Pixelfed and PeerTube and Lemmy and Mastodon are actually pretty different experiences. They don’t really do the same thing, they don’t appear to have the same verbs and nouns. So using one to talk to the other is actually a little weird, not because we’re trying to make walled gardens, but just because the focus of Lemmy is on the threaded topic, and the focus of PeerTube is comments on videos in my playlist.

    The fact that they can cross-talk at all is kind of an accident. Each system wants to federate with itself, and so they have a protocol to do it. And because it’s an open protocol, anyone can use it. And it is intentional that any compatible software should be able to use it, so Mastodon and other microblogs can cross-talk, that’s on purpose. But with these different “kinds” of services, they all picked the same protocol because it already existed, it already worked, and it met their needs. I don’t think the people making Lemmy really intended PeerTube users to use it, even though it’s sometimes possible in particular ways. They’re compatible because they both used parts of the same protocol, and so when you put them together they happen to have overlap, but that’s almost a coincidence.

    The reason SSO sometimes comes up is actually to solve a UX problem that’s plagued the fediverse since the beginning. If I’m a user of lemmy.ca, and I’m looking at lemmy.ml because I got there from a link it Google out something, and want to comment on what I see there, I can’t. Not directly. I can’t click the join button or follow a user or any of it, because this site is not my site. I have to first go to my site, where I have an account, and then find this content on my site, and then interact with it there. That sucks and has always sucked. So one of the proposals people have pitched to fix it is if I could login to lemmy.ml directly with my lemmy.ca account, then I could drive it remotely, in context, while maintaining my actual account somewhere else.

    The downside of this is that a whole bunch of random sites have tokens for me, every instance has way more “users” than users, and if any one of them has a security incident then it doesn’t just affect the users of that instance, because that instance also has keys for a bunch of other random instances. And overall the way I’d login on the remote site is to type my home site’s address, to kick off the SSO login, but if I’m doing that anyway I could also type that in and just have it redirect me there natively. So not great.

    If we’re talking about using SSO just to only have one credential, this is actually better handled with normal, existing, SSO. Like OpenID or whatever. If Lemmy and Mastodon and PeerTube and PixelFed all allowed creating an account with an existing SSO solution, of which there are several, then you can already create an account on each of them using the same identity provider and not make any new accounts. This is likely cleaner than requiring each of them to be, themselves, an identity provider just so they can all login to each other so you can start with any one of them natively, but from there only have one identity for all the rest. That would add a bunch of extra requirements to being a valid implementation, and maybe lead to some bad or insecure identity providers, and not give that much benefit in return.

    But I love SSO as a concept, so we should definitely support the much simpler thing, which is that all FOSS websites support SSO standards, not for fediverse reasons, but just because it’s nice in general. For me 😛


  • And so I’d say this also answers your broader questions. Since Activity Pub doesn’t allow me to join other servers, it also doesn’t allow me to join other sites.

    So a Lemmy post may be compatible with a Mastodon message sent to a group or something, that’s only because the messages Activity Pub sends are similar. But PeerTube is different software with different buttons, and the existence of those buttons on PeerTube doesn’t change anything about what buttons Lemmy has, and I can’t “login” to a PeerTube server with my Lemmy account, so I don’t gain any special abilities outside of what Lemmy can do.

    The only way it would be possible is if Lemmy added a feature for uploading videos that sent the same kinds of messages to other servers that PeerTube sends. Then, if they did that, someone on a PeerTube instance could see these messages coming from Lemmy and interpret them on their server as a PeerTube video or something.

    But all that Activity Pub allows is exchanging of information between sites. For them to interoperate in a way that makes sense, they need to exchange the same kind of information.


  • Quick clarification, because I can’t tell from your words if you’re confused about the concept of federation or not 😅

    If by “join” other servers you mean use their site as if logged in, or like you have an account there, then that is not federation. That’s single-sign-on (SSO) and is not a feature of the fediverse (Mastodon, Lemmy, Peertube, etc). That would be like the “login with Facebook” or Google buttons around, where by having this account on site A, you can instantly signup on site B without making a new password or anything. That’s not how federation works.

    Federation is like email. I can have an email with GMail, you can have one with Proton, and someone else can have Yahoo, and I can send an email to you anyway. It doesn’t mean I can “join” Proton with my GMail account, it doesn’t mean I have a Yahoo account, it means I don’t need a Yahoo account to communicate with Yahoo users.

    But, if by “join” you meant “join a community” as in subscribe to updates from a group on another server, then most other people’s answers apply. I wouldn’t call that “joining a server”, though, because servers host many communities and you’re not joining all of them.

    Joining a community works like joining a mailing list. Activity Pub allows accounts on different servers to communicate without an account on their own server, so my account would send a message to your account saying “I’d like to subscribe to this community, send me a message whenever something happens on it”, and then the other server says “okay, will do”, and then after that will periodically send my server messages saying “hey, here’s that update you asked for”. And when I comment, like right now, it’s like an email being sent from my server to yours, and then your server puts it into the history.

    This allows my server to present the community from your server to me, without me having account on your server. Without me having to “join” your server, I’d say.





  • Welllllllll, Taler is actually exactly the wrong suggestion for this usecase, because Taler requires all spends to be redeemed from Vendor to Issuer non-anonymously, which gives the Issuer 100% control and say which vendors are allowed, which is exactly the thing Visa and Mastercard are using to exert control.

    If there were competing Taler networks and Steam supported all of them, that might be okay because one of them might happen to not be dicks, but if there’s just one or two then Taler is designed from the ground-up specifically to enable this bad outcome. It’s actually one of their features!

    Sorry.


  • Honestly, I struggle with this myself. On the one hand I like the diversity of clients; it feels like a sign of strength of the community and protocol that there are many options that have different values. But the cost of this diversity is that it makes things more complicated to coordinate, and different people with different values have different opinions on what a chat client should even want for features.

    Something like Slack or Discord can roll out a server feature and client feature to all their clients all at the same time and have a unified experience. But the whole benefit of FLOSS is that anyone can fork the client to make changes, and the whole point of an open protocol is that multiple independent clients can interoperate, and so there’s a kind of irony in me wanting those things, but those things producing a fractured output.

    So I think XMPP, as a protocol, does the best compromise. These differences between clients and servers aren’t just random changes in behaviour or undocumented features, they’re named, numbered, alterations that live somewhere and are advertised in the built-in “discovery” protocols. The protocol format itself is extensible, so unexpected content can be passed alongside known content in a message or a server response and the clients all know to ignore anything they don’t understand, and virtually all of the XEPs are designed with some kind of backwards compatibility in mind for how this feature might degrade when sent to a non-supported client.

    It isn’t perfect, but I think perfection is impossible here. A single server and client that everyone uses and keeps up to date religiously with forced upgrades is best for cohesiveness, but worst for “freedom”, and a free-for-all where people just make random individual changes and everything is always broken isn’t really a community, and XMPP sits in the middle and has a menu of documented deviations for clients to advertise and choose.

    As for security, that can be mostly solved with libraries, independent of the rest of the client or server implementation. Like, most clients used libsignal for their crypto, so that could in theory be audited and bug-fixed and all clients would benefit. Again, not perfect, there’s always room at the interface between the client code and the library code that’s unique, but it’s not as bad as rolling your own crypto.





  • XMPP doesn’t change very very often, but there’s actually tons of XEPs that are in common use and are considered functionally essential for a modern client, and with much higher numbers than XEP-0004

    The good news, though, is that mostly you as the user don’t need to care about those! Most of the modern clients agree on the core set and thus interoperate fine for most normal things. And most XEPs have a fallback in case the receiver doesn’t support the same XEPs.

    I’m general XMPP as a protocol is a lightweight core that supports an interesting soup of modules (in the form of XEPs) to make it a real messenger in the modern sense. And I think that’s neat! But you can’t really judge the core to say how often things change.