this post was submitted on 22 Jun 2023
8 points (100.0% liked)
Fediverse
19 readers
2 users here now
This magazine is dedicated to discussions on the federated social networking ecosystem, which includes decentralized and open-source social media platforms. Whether you are a user, developer, or simply interested in the concept of decentralized social media, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as the benefits and challenges of decentralized social media, new and existing federated platforms, and more. From the latest developments and trends to ethical considerations and the future of federated social media, this category covers a wide range of topics related to the Fediverse.
founded 2 years ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The softwares can federate with whomever by default, so your second thought was spot on.
This is a perfectly valid reason to stand up your own lemmy/kbin server. I'm considering the same thing myself. An instance like you're describing would certainly need far fewer resources compared to a public instance, just keep in mind that you'll need to set up and maintain it on your own; not a huge task for a single user, but it's a task.
And to be a bit more clear on the terminology, you're considering setting up an instance that has new user signups and new communities disabled, but with federation still enabled, correct? If not, than disregard everything in my last paragraph.
Rather than a kbin/lemmy instance, I'm thinking of a separate codebase altogether.
As I understand, both kbin and lemmy implement the activitypub protocol, similar to how gmail/outlook implement SMTP.
So having an activitypub-compliant app would be sufficient to read the data from kbin/lemmy/etc.
This would be a side project for myself to learn a new language, e.g. golang backend.