Mbin is alive and kicking! A community-focused fork of Kbin, which has tons of improvements, features and bug fixes. Mbin is a federated content aggregator, voting, discussion and microblogging platform.
Feel free to host your own instance on the fediverse! If you are already running Kbin; migrating is straightforward towards Mbin and experience the benefits yourself.
@jcrabapple Thank you so much for trying out Mbin again! For the reasons you mentioned the fork was created in the first place. We embracing the Collective Code Construction Contract, meaning no single maintainer anymore. We are all maintainers now. For the community, by the community! It accelerated development, contributions and PRs! Feel free to also join the community on Matrix: https://matrix.to/#/#mbin:melroy.org
@melroy looking at the open issues on GitHub, I'm surprised that renaming magazines -> communities or making it easier to get to the posts of my communities easier haven't already been requested. While I like the fact that Kbin/Mbin are using a stack I'm familiar with, I can’t be the only one who has to repeatedly explain that magazines = a Reddit sub or Lemmy community and how to get to the view of just the posts to the communities you subscribe to.
@kreynen We try indeed to keep the issue list as short as possible atm. We are aware of many bugs and improvement proposals, including the one you mentioned. Kbin has like 480+ issues, which isn't helpful at all for the community. At this stage of development PRs are more helpful if you can imagine.
That all being said, feel free to discuss this in the matrix community rooms: https://matrix.to/#/#mbin:melroy.org We can discuss it there, we could even start a poll for it.
@melroy@kreynen Apologies of this is addressed elsewhere or I missed the memo, but does Mbin support the Kbin API? I’m not even sure if that’s merged yet in the kbin repo. That API is definitely holding back kbin support in a Fediverse client I’m developing.
@melroy@kreynen Fair enough, so long as there is a differentiator when devs hit the API so we can have some mbin vs kbin detection for the one-offs it shouldn’t be a problem. It would be just like supporting the differences between Mastodon and Calckey.
@vertana@kreynen Could you go in further details how do you currently distinguish between the different APIs of the services you just mention. I understand exactly what you mean, but let me see what the best implementation might be for Mbin. I think also Kbin needs to be changed in that regard.
@melroy@kreynen Right now, it’s been made pretty easy for me. All the services have different API endpoints, so if it has some X API call that returns data in Y format we can assume it’s Z service. In the case of forks like mbin? Most of those share the API with upstream, so the same calls work. In the case of mbin specifically? I would expect some kind of API endpoint to get the server info and one of the fields should define the software running on it. Then I could say “hit the endpoint”, discover its kbin or fork, the ask server for info and drill it down to exactly mbin (in the event your API differs down the road or you just want to uniquely identify).
@vertana@kreynen I was indeed thinking of the same end point. Or even trying to respond with server info in an existing end point. I don't see any other way.
@melroy@kreynen Here is an a really good example of an endpoint to surface that. Lemmy has a /site endpoint that surfaces basic server info and such a place is the perfect spot for an identifier. Not sure if kbin has an endpoint like this, but you could just tack on an extra field and devs could check for existence and content of that field.
This site is already aimed at /site, so you can scroll down a tiny bit and press “try it” to see the /site response.
@melroy@kreynen if you add a field to an existing endpoint and make it an optional field, then it should be doable to fit right in. Existing kbin clients would continue rolling along and (presumably) getting your kbin-conforming features.
Extra niceness mbin adds? Clients can check for that extra field and start down the road of loading the “if mbin, make sure we load the mbin extension on top of kbin module for those extras”.
Which will tell you more info about the server. You can leverage this nodeinfo endpoint on all federated software. Including but not limited to Mastodon, Mbin, Pixelfed, Calckey, Firefish, etc. That being said I'm planning to add a simple GET /api/server end-point that will run basically the same info.
@melroy@vertana I'm following the MBin fork, but what I'm really looking for is a statement about the priorities of the forkers beyond "not being blocked by a single dev". I supported the Backdrop fork of Drupal because they made a compelling case about why they were forking at https://backdropcms.org/philosophy. Drupal also has a BDFL and it can take longer than many people's patience for him to find people he really trusts to delegate responsibilities to. Not liking the BDFL model isn't enough... 1/2
@melroy@vertana Not liking the BDFL model isn't enough to make a fork successful. I had some ideas for a KBin instance for the Drupal community that could replace groups.drupal.org and drupal.stackexchange.com with a more POSSE model when I learned it also used the PHP/Symfony/Twig stack, but the Drupal community is never going to accept an unintuitive user experience.
@melroy@vertana Not sure what you intended w/ the previous comment. It's true. I don't need to use/contrib to any of these ActivityPub projects. I don't need a CMS project either, but I believe we benefit from collab vs. devs re-inventing every wheel. I'm not going to fork KBin myself just to address the UX issues nor am I going to get involved in Lemmy as it's not a stack I know well. I would consider contributing to a fork if improving the UX was a priority of the devs leading the fork... 1/2
@melroy@kreynen Not sure what the plan is, but just in case this is an issue: When I visit the first link from a few days ago (https://kbin.melroy.org/nodeinfo/2.0) it is no longer found. Your new 2.1 link is but it’s missing all the information from the previous link (such as the specifying mbin name).
I just hit these real quick on Safari iOS, so it could also be that if you’re sure I’m mistaken.
However, if you wish to just subscribe to an existing (remote) magazine between instances, you can just search on the magazine: @magazinename@instance.com. By pressing the top right search icon and perform such a search. I hope I could still help you out.
@evilgardengnome So the best advise I can give you now is; to create a new magazine on another instance. And post a thread/blog post in the old magazine, mentioning you migrated to another instance.... You agree?
@melroy
Yes. Outside building the Move activity, that's the best choice.
I've been meaning to learn more about fedi stuff, so may look at the activity, but that's a big lift on top of life and a day job (software dev, so inside the wheelhouse).
Add comment