/kbin meta

5 readers

2 users here now

Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign

founded 1 year ago

clients are the libre future; I hope kbin catches up (kbin.social)

submitted 1 year ago by [email protected] to c/[email protected]

3 comments fedilink hide all child comments

On desktop kbin is 5x better than vanilla lemmy.

But on mobile I have several FLOSS lemmy clients. They all have their pros n cons. Their development is spread out with different projects. Work and the responsibility are distributed from the main lemmy maintainers.

The kbin webapp is pretty good, but not as good as a native client. There is of course only one.

My feeling is that designing for clients (having an API) imposes some kind of discipline on projects. Like you can't just do whatever willy nilly.

My other feeling is that kbin is setting up to be like iCloud whereas lemmy is more akin to sftp.

Thoughts?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 11 points 11 months ago (1 children)

There are mobile apps in development and the API is coming along.
Kbin is still just a prototype though, but it's moving along nicely.

My other feeling is that kbin is setting up to be like iCloud whereas lemmy is more akin to sftp.

I've no idea what that analogy even is, but I think the differences are mostly technical (PHP vs Rust) and UX.
Both implement AP a bit differently, but at the end of the day, they're still AP aggregators.
And that's ignoring the political issues around lemmy's codebase ofc.

[–] [email protected] 1 points 11 months ago

Are you talking about the dev?