this post was submitted on 06 Mar 2024
251 points (88.9% liked)
Fediverse
28396 readers
1069 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Why? If your argument were "users of the system need to have these type of tools ancillary utilities to be able to use the core product", I certainly agree. What I am failing to understand why do you think that this must be the responsibility of the developers of the core product.
What is so bad about the developers delegating this away?
Developmental drift and code rot. Both parties can try their best to keep up with changes and adjustments, but an external resource is always going to lag behind of core. This isn't necessarily bad, but having it in core at least kind of ensures that future development and updates have to take into account how those things are affected.
Couple of reasons:
It's core. Super crucial parts of the platform should, ostensibly, be done by the core development team, who can ensure they have someone to work on it as needed. If you delegate the development of a core feature to someone who isn't part of the core team, there is always a possibility that said person will fall off the development wagon, and the feature either languishes, or core team is stuck having to babysit a part neither of them directly worked on.
The people building the platform need to have a significant understanding / frame of reference for these parts and how they work. When doing future feature development, they need to be keenly aware of which features touch which fixtures.
Trying to delegate this kind of thing to volunteers is just such a mixed bag in terms of Quality Assurance that I cannot recommend it. You might get something great! But regardless, you're delegating to someone who is a relative stranger, who may have done things in a hacky way that will break something else later on, or may have not even bothered with code or documentation. Worse yet: trying to reconcile a volunteer's PR with upstream is not always a cakewalk, and this can drag on and on and on. I've literally seen projects with PRs open that sat in that state gradually getting adjusted, tweaked, and rebased by various volunteers who came and went, that are still open to this day.
I assume you missed all the microservices hype cycle of 2015? The whole idea was to isolate the dev teams into their core functionalities and to only let them talk through specific APIs.
Speaking as someone with 20 years of software development experience and from the work on Fediverser: all I need from the Lemmy devs is in the API that already exists. None of the functionality related to content moderation and instance administration needs to be implemented in Rust and frankly trying to tie it with the core code would make development slower.
Can you trust me on this one? This is not about the Lemmy devs being dicks or not wanting to do this work, this is me saying that they are right when they say that someone else could take care of this instead.
I'd love it if the API that exists was more reliable... It's getting better, but the amount of basic features that didn't work (usually without specific combinations of params or unknown ranges, but sometimes not at all) is pretty crippling. (If there's a central place of discussion, I'd love to hear about it...I don't speak rust or flutter, but I've had to muddle through source several times)
I've never done anything as a mod so I have no idea what kind of tools they need, but I noticed enough basic parts to build all sorts of things.
There's definitely no reason to build it into the core though... Why put it on the machine busy serving everyone? You could do stuff so much cooler if you offload it... Like you could track mod actions against users/communities/servers, give a sample of random posts across their vote distribution, show the top few communities they get down voted.... All things psychotic to even consider in the core right now, but a reasonable project for a separate system
And since you seem like you'd get it, I want to share a win I made today. I've got a lemmy app I want to mix feeds (including between accounts and servers) to make a unified feed algorithm on your device. I also want it to support kbin, and maybe more... I took a couple cracks at it and charted out several designs, but I was getting too deep into abstraction.
Today, I finished working on a ridiculously generic abstraction layer - it handles not only tracking pagination, buffering, and preprocessing, it also enumerates all of the options in the Lemmy sdk so I can auto magically build most of the controls when I update. It also disambiguates resources (and actors) across instances and could describe valid actions you can take on it (I think that might be too far, so I'm resisting the urge... This time)
Everything is done through the account level, everything knows where it came from and can call the API by passing itself to its account to be worked on. It's also neatly serializable, you just have to write one function to pull the next page, and the rest is just an absurd amount of generics
Now, if I can figure out how to translate all that into a usable UI, I'll be getting somewhere...
I just had to share that with someone who can appreciate crazy data flow, it's been in the back of my head for months and today (after pulling my hair out for an hour and realizing I was forgetting to actually pass the posts to the UI) it worked beautifully
I like to think of it like this - many hands makes for a very stable project. Stable as in reliable, but also stable as in resistant to change.
Everyone is going to pull in a different direction, and it kind of averages out and slows things down.
Right now, lemmy is extremely immature. It's amazing how well it's held up really. There's a lot to go to get to a solid baseline - just enough to keep
If everyone dogpiled it, someone could easily solve the image problem. Granted, that might block someone else working on the database, and changes to improve or extend federation would likely be set back as they step on each other's toes.
We could still probably quickly get popular features quickly... For example, one person could get more useful mastodon and kbin federation going in a reasonable period of time. But then, when the core team goes in to overhaul the database or the API, now they need to make sure they don't break it - and the person who did those changes won't have the same vision as the core team, and now you have to either refactor the whole thing or work around it until it's causing too many problems
Certain things can be spun off more easily than others - I think other people have totally taken over deployment of instances.
Some are good candidates but require more maturity - like if they handed off jerboa and the default web client, there's one place that would need to be reinforced - the API.
Way down the road, they could build plug-in/mod interfaces so instances could choose feed algorithms, or individuals could come up with their own karma systems, or all sorts of other things.
To get to that point, you have to have a clear vision and stable growth though - that takes time, and is better done by an individual or small team keeping things heading in one direction
You know that you are riffing on the theme of "The Cathedral and The Bazaar", right?
Anyway... For this to work well things needs to be enforced at the API level, but APIs are exactly that: a contract between two separate applications that need to interface with each other programmatically.
I for one wished that "the API" was not something ad-hoc and developed exclusively for Lemmy, but as long as "Lemmy's API" can be used as a de-facto standard for discussion-group applications on the Fediverse, then I don't mind working with it.
Huh, I've never actually come across that, I've only gotten it indirectly. I bet my first mentor put it on in my head, the guy built out our entire system, then a v2, with one intern while the rest of us extended the framework he built.
And that's the sad part... The Lemmy api is not only not that, federation is an API+ that gives an amazing starting point. As far as I can tell, the lemmy API was made with the official clients in mind, and everything else was an afterthought made in a hurry during the last Reddit Exodus
I started reading through the kbin API, which starts with "here's a link to activity pub standards, they're surprisingly readable". They were... It's unwieldy in a lot of ways and maybe too all-encompassing, but they left so much on the table.
For one, uri ids. Lemmy has them for everything (which is nice), but they aren't directly usable. You can get the local ID for the home instance, but if I've got a url for lemmy.world I want to see on my instance, my only option is a search. Which should kick off federation, but what if it's there already? I want an endpoint to resolve it (or even to tell me it's not here right now so I can fall back).
And the way they handled metadata is pretty awkward... They next objects inside of collections of activity data and object properties, which is annoying because it's so inconsistent. Like, if you get a comment response, it gives you the comment reply, which is basically a comment without the usual metadata like vote count or the full actor object.
It gives you too much, then suddenly too little - I don't need the bio, tagline, and banner of a server every time I see a post, and I also don't need it for the community and user
But I do need the comment votes when I get a reply - I'll wait on the comment chain and root post, but I don't want to have to build a post-body only component to show while I wait to replace it with the whole thing
I do really like that they autodoc everything... Even if a lot of it is indecipherable with no context offered. Like the honeypot parameter on getPosts... It's actually intended to be a honeypot. Like if you set it to true, it's supposed to not give you posts, or log you or something? I tracked down a one line confirmation on GitHub which left me baffled. I had to try it... It didn't seem to do anything
/Rant
It is getting better though, the amount of completely breaking changes that pop up is very frustrating, but this time around it is significantly improved