A home for discussion of Lemmy apps and tools for all platforms.
RULES:
An extensive list of Lemmy apps is available here:
Visit our partner Communities!
Lemmy Plugins and Userscripts is a great place to enhance the Lemmy browsing experience. [email protected]
Lemmy Integrations is a community about all integrations with the lemmy API. Bots, Scripts, New Apps, etc. [email protected]
Lemmy Bots and Tools is a place to discuss and show off bots, tools, front ends, etc. you’re making that relate to lemmy. [email protected]
Lemmy App Development is a place for Lemmy builders to chat about building apps, clients, tools and bots for the Lemmy platform. [email protected]
I have some interest in trying to take that on if it's really unmaintained now. I use mlmym and want to make sure we continue to have an interface that works w/o JS. I have relevant web programming experience, but not with Go specifically.
@[email protected] FYI, if you're still here.
I've started changing some smaller things over on Fedihosting-Foundation-Forks/mlmym. I don't really have time, motivation or Go knowledge to fully maintain and develop new functionality there, especially as I don't use it myself, but I'm currently planning to keep it on life support at least and see if I can at least fix some stability issues.
I also already forked and updated go-lemmy, which should now support the latest Lemmy 0.19.11 APIs.
Currently the primary focus for this is to have builds for old.lemmy.world, but I wouldn't be opposed to have this used as a generic repo if other people want to contribute. I'm currently not planning to intentionally break things in a way that would prevent usage outside of Lemmy.World, but unless there are other people interested in contributing as well, I will primarily just focus on ensuring compatibility with the Lemmy version we are running.
Thanks. I'm still learning both Go and the codebases involved. I'm pretty limited on free time where I've got both large enough blocks of time and energy to concentrate effectively on this. I'm also not very enthusiastic about taking on the administrative aspects of running an open source project -- I'm only really interested in keeping a JS-free version of Lemmy usable -- so contributing changes to a common community fork you've already got up and running sounds good to me!
I do have some specific issues in mind that I'd like to implement fixes for once I'm up to speed. In particular:
I may take on some other issues after that, but those three are what I want to fix most right now.
Federated image links to non-lemmy websites sometimes show up as image_proxy links from the poster’s instance. This is a really annoying issue that results in misleading domains showing up next to posts as well as breaking image display in the post itself.
that is not directly a mlmym issue, it's that people copy links on instances with image proxying enabled and use them in new posts :|
feel free to also raise them as issues on the repo directly to have them documented.
by the way, we run the version on the main branch on https://mlmym-unstable.lemmy.world/, although it does have a domain lock to lemmy.world.
Hmm. That doesn't really mesh with my understand of how certain prolific posters post (e.g. via automation), but digging into it a bit more, I do see the proxy link via Lemmy-UI even on the poster's instance, so there's something besides just mlmym involved here -- whether that really is inappropriate copy-pasting or a lemmy bug or what, I don't know yet.
Regardless, the fact that the image doesn't load in the post at all for those links seems like an mlmym bug that should be addressed; it's loadable via Lemmy-UI.
I've set up a new GitHub account for association with my lemmy account and will create issues on your repo in a little while.
Edit -- Issue links for future reference:
and just now there has been a PR merged in the upstream repo after i spent some time to get a fork properly set up...
@[email protected] @[email protected] @[email protected] are you still reading on any of these accounts? are you planning to return to maintaining mlmym?
That would be great!
Playing devils advocate. Lemmy isn't reddit and the only reason people used old reddit was because new reddit was unusable to them.
As with new context and new front ends that Lemmy has, no one with the technical skills seems to care about this enough and blaming Lemmy Devs for not tiptoeing around unmaintained software so development grinds to a halt isn't fair. It's like saying "they don't want to support it, and I don't, but you shouldn't spend your free time doing so".
Lemmy isn't reddit and the only reason people used old reddit was because new reddit was unusable to them.
If “because new reddit was unusable to them” is a polite way of saying “because new reddit is a bloated, buggy, and worthless coding disaster” then I agree completely.
New lemmy isn't nearly as bad as new reddit, but I still prefer old because it's more compact. The formatting on new vs old displays 7 vs 12 posts on one screen, which feels like a lot of wasted space. I know, first world problems and all that
Lemmy isn’t reddit and the only reason people used old reddit was because new reddit was unusable to them.
The comment in the OP shows that at least one person cares.
Mlmym also has the "show images" button that the default Web UI doesn't
no one with the technical skills seems to care about this enough
That's what this post is trying to solve
blaming Lemmy Devs for not tiptoeing around unmaintained software so development grinds to a halt isn’t fair.
I'm not blaming the Lemmy devs (I should rephrase if the post comes as such), the goal of this post was mainly to find someone interested in keeping mlmym up-to-date, not to blame anyone
Maybe petition the Lemmy devs to not pointlessly break API v3 since they're moving to v4?
Isn't the whole point of having different api versions to not break compatibility, so apps can continue using v3?
Yep, and that's how we do API versioning at work. One app is on like API v9 now, and I think we support back to v5 or maybe even v4.
Their justification is that pre v1.0, you can break whatever you want whenever you want. But when you've got a large community of people developing for the ecosystem over several years, it's kind of a slap in the face to keep breaking the API. I appreciate that 0.19.0 - 0.19.11 has been fairly stable, but breaking v3 while also rolling out v4 is just inexcusable.
I get that v3 will eventually need to be deprecated, but you'd think they'd put all their breaking changes in v4, let v4 stabilize and run concurrently with v3, and then drop v3 a few versions down the line.
But what do I know? It's not like I do this for a living. Oh, wait...
Their justification is that pre v1.0, you can break whatever you want whenever you want.
They are not wrong. If you are developing an application against a backend that clearly states "we are following semver. This version is not 1.0, therefore no API is guaranteed to be stable", and you go on to write a client for it anyway, you don't get to complain later when they make breaking changes.
Alternatively, you can just stop relying on their ad-hoc APIs and push for them to implement Lemmy with focus on the ActivityPub API. That is already an standard and if you come up to them with issues against their AP implementation, they will be a lot more likely to listen to you.
In a comment one of the main devs mentioned worst case scenario that they could be supporting 0.19 for a long time so they're trying not to rush 1.0.
It's open source. If somebody wants to fix v3, they could submit patches.
It's unfortunate that v3 is stalling but nobody is paying the devs so they can prioritize however they see fit.
I also think that right now developing missing features is more important than old APIs.
Features can be developed independently of the API and/or added without introducing breaking changes.
I'm just a scripting monkey for a systems engineering/admin team, but I have one system integration that is being fireman carried by a ton of my code. I've since learned that there are entire consulting companies built off selling a slightly expanded version of what I've one man army'd together. Maybe I overestimate my skill, but I feel qualified to talk about large projects and long term sustainability.
I'm convinced that people who talk about things like backwards compatibility as if it's super difficult just aren't willing to try. I won't say shit like that is super easy, but it's not black magic.
I think there's a lot of programmers out there more interested in building shit than ensuring any sort of quality, that it'll be maintainable longer than the next code review, or in thinking about any downstream effects of their code beyond the limited scope they're developing in. Stuff like backwards compat is largely just another design pattern in a sea of them that you learn through experience. But you have to try it to learn what works and what doesn't. Go try folks.