Is there a way to set it up so user@example.com can be a lemmy account and also a mastadon account? I seen people using subdomains like user@lemmy.example.com and user@mastadon.example.com is this nessasary? Could u also set up a matrix account with the same user@example.com? If not what woukd be requured to change to make this possible?
You do it via a webfinger. But the service itself has to request a specific resource in order to route it correctly. For example, mastodon and pixelfed ask for the same resource, so both services will end up getting the same service’s account.
Has anyone actually done it? I cant seem to find any decent guides on how to do it?
Each fediverse service is different. Matrix has it’s own webfinger configuration, as does diaspora, and mastodon. However, it looks like all ActivityPub services use the same webfinger configuration, which means that this method doesn’t work for donations trying to reference user@domain.tld for activitypub. I would presume that the first AP service you have listed in the response is going to be the account that each AP service will federate with.
Here’s a little bit about what I’m talking about:
No, not in the example that you’ve set up. The username is always @user@domain. This is like asking if you can have the same email address on Gmail and Hotmail or whatever. You can have the same user part, but not the domain.
People that have used user@x.domain and also user@y.domain is allowed because they’re different domain names.
So u cant just do some weird routing rules and make it work.
Technically you sort of can do that with email. Most providers let you verify you own the other email and then use the other provider’s SMTP to send from a different address.
Matrix and ActivityPub are different protocols. You cannot use them interchangeably. However, you can register the same user@server for both Matrix and Mastodon/Lemmy, and theoretically you even could set up some kind of single sign-on that’ll let you use the same login system for access to either.
The hard part is using the same account for Lemmy and Mastodon. ActivityPub is built for interoperability, but it doesn’t have a universal shared account design.
Theoretically, in the “you’ll have to write a couple of thousand lines of code to hack together a prototype” sense, you could unify multiple services. I’ve theorised about such a service before.
What you would need is a separate piece of software that will a) receive incoming posts from other servers and redistribute them to multiple services (Lemmy, Mastodon, etc.), b) catch outgoing posts and use whatever means necessary to also make all other services for the same account aware of the post and c) ensure that the necessary signing keys are the same across all services.
The first part should be relatively easy to do. The second will rewuire modifying code on all services, of use some kind of man-in-the-middle attack on your own outgoing traffic and modifying the database directly. The third part can probably be done by copying one field in a database and pasting it over another.
Alternatively, you could take another approach: reimplementing the Mastodon API into Lemmy, or the Lemmy API into Mastodon. That’s not exactly trivial (putting the Lemmy API onto Mastodon would probably be easier but comment chains would be broken without Fedifetcher) but the frontends and apps are separate from the backends, so it’s all very much possible if you put in the effort.
ActivityPub itself describes a client-server protocol that should theoretically be independent of server implementations. If all services would implement this protocol, it wouldn’t matter what app or server you use, because all apps would be able to connect to all servers and exchange all kinds of messaging. Unfortunately, the C2S spec is rather underdefined (it provides no standardised way to log in, for example…) and I think there are only two or three server projects with partial support. Client support is even worse, I believe there’s one Android app and a few web interfaces that look unfinished. Most ActivityPub services operate through either the Mastodon API or their own bespoke API when it comes to server users actually posting content.
I’m not sure if such a system would be very usable. Lemmy behaves very weirdly when it comes to ActivityPub traffic (using boosts to ensure every post and comment reaches every server) so following Lemmy from Mastodon isn’t a great experience at the moment.
If you don’t care to interact with Lemmy servers from Mastodon or vice versa, you could abuse the webfinger protocol. If you tell Lemmy servers that user@server is located at user@lemmy.server and Mastodon servers that user@server is located as user@mastodon.server, you’ll still appear as user@server on either and you’ll probably be able to reach most ActivityPub servers without any issues. However, this does mean that Mastodon users will no longer be able to interact with you on Lemmy and vice versa. You’ll also end up with some overhead, as every server connecting to yours now needs to be fingerprinted to check if it’s Lemmy/Kbin or Mastodon/other.
Thank you for the very detailed explanation. I figured for services using a different protocal would be easyer as they can be handled almost independantly.
Would i need to modify the code of every services to man in the middle myself surly since i control the private key i can just do it after it leaves the service then if i pipe that back to my “universal” incoming it would distribute it to the relevent services?
I dont understand why the last approach breaks mastadon-lemmy interaction? It seems like the best solution if it wasnt for that.
deleted by creator
I don’t know if there’s a service that provides both functions. I’m sure there’s a way to do it - Lemmy posts are already accessible through Mastodon. Currently, I assume you would need the instance itself to offer both services under one account.
Well i recently got myself a new server and domain and was going to self host all my things though it would be cool to have the same username and domain across services without needing to do subdomain shenanigans.
