- cross-posted to:
- fediverse@lemmy.ml
- cross-posted to:
- fediverse@lemmy.ml
Highlighting the recent report of users and admins being unable to delete images, and how Trust & Safety tooling is currently lacking.
Highlighting the recent report of users and admins being unable to delete images, and how Trust & Safety tooling is currently lacking.
Was going to say “another one of these?” but, wow, the article really further highlights the childish nature of the Lemmy devs… Can’t wait for Sublinks to reach feature parity and become main stream, so we can leave this dark phase behind.
You don’t understand how open source works. You are not entitled to any features. Let the devs go on their own pace. A lot of open source projects shut down because of similar reasons.
Likewise, an open source project can totally die if they refuse to engage with the needs of the users. The lack of moderation and content management tools have been a longstanding criticism of Lemmy, and instances will migrate to alternatives that address these concerns. It is a genuine legal liability for instance operators if they are unable to sufficiently delete CSAM/illegal content or comply with EU regulations.
But opensource projects are more likely to get dropped by devs than losing their userbase from what I’ve seen. I could be wrong. Both our points are true. That’s the best part of fediverse. If one doesn’t like lemmy, they are free to choose an alternative. I just don’t agree with demanding features from open source developers. There is a distinct line between demanding and requesting. I’m not saying lemmy is perfect. Maybe Sublinks would be better. Let’s wait. But even Sublinks won’t be sustainable if users do not respect developers time and patience.
I think there is also a distinct line between demanding, for example, a new animated avatar feature and demanding a way to delete child porn.
Reasonable.
While I think you’re correct about it ultimately being their project, and that users are in no place to demand or expect anything, this thing takes on whole other dimensions once a project is all about building a social platform. Particularly one where volunteers host part of the network themselves.
It’s one thing to look at some random demand to write everything in a P2P architecture because DNS is too centralized. When I worked on Diaspora, I literally saw people demand stuff like that, and laughed it off. I’m trying to build a platform that exists today, not some pixie dream bullshit compromised of academic circle-jerking.
But when it comes to basic table stakes for participating in a network that already exists, things change a bit. This is especially true when you’re connecting to a global network that has:
Suddenly, it makes a lot of sense to say “you know what, admins are going to want to filter this shit out, maybe it’s reasonable for them to have some tools and fixtures that are part of core.”
Unfortunately, these devs are the kind of people who scream angrily when someone says “Hey, this thing doesn’t actually respect local image deletes / GDPR stuff / content deletion on account deletion”. To me, that’s fucking insane.
You don’t know how social networks work. They only survive based on network effects, if they don’t have the most basic functionality that users expect (like complying with privacy legislation), then they will fail to reach critical mass and be outcompeted and die.
If the devs don’t want to provide the most basic functions that any user of a social network would expect, they’re welcome to be downvoted to hell and have their project go back to being one of the millions of forgotten and unviewed personal github projects.
Open source projects die because it takes both technical talent and attention to your users to make a project successful, and for-profit companies often pay different people to do those.
The entire point of the “fediverse” is to combat the network effect. Don’t like Lemmy? Move to another app and still communicate with people on Lemmy. Plus it’s all open, can’t find an app you like? Build one or wait for someone to build one you like.
No, it’s not.
The purpose of the fediverse is to decentralize control of the network, it does not eliminate network effects in any way shape or form. At the end of the day a social network is only as valuable as the users using it and contributing content to it. If they don’t find lemmy pleasant to use, they’re not going to say “let me jump to mastodon” they’re going to go to Reddit.
You really don’t understand network effects if you think you can just sit around and wait for basic functionality and expect your network not to die.
We can expect them to follow the law. And yes this means implementing required features to comply with the law.
Nothing here is breaking any laws. I don’t know why OP thinks the GDPR applies here, it doesn’t.
It does apply, but not to the Lemmy devs, but to the instance admins.
As it stands, you can’t legally host a Lemmy server in either the EU or the US (or places they can reach) and federate with the 'verse at large without fear that the authorities will come after you.
This is not true at all, you can host a instance in the USA for free and not be subjective to the GDPR. You’re not selling anything, or marketing anything or doing any data collection to be sold. It %100 does not apply.
GDPR article 3, and the EU-US Data Protection Umbrella Agreement concluded in the US in December 2016 which makes it US law disagree.
Yeah no it doesn’t.
https://gdpr-info.eu/art-3-gdpr/
Go read it ffs.
Lemmy instances offer services to me as an in-EU data subject, and that makes it subject under the very Article 3/2 (a) you linked.
Since there is federation, a US-based instance would still be a data processor if it IP blocked be as coming from the EU.
I did in fact read it.
It’s honestly mind-blowing. At every turn, for no reason at all, they act like a bunch of dicks. It’s like they decided to run a community project based on engineering prowess alone, and nothing else.
Except the engineering isn’t all that good, either.
Not only that, but the developer Dessalines apparently denies the Tiananmen Square Massacre and praises the Uyghur Genocide. Absolutely disgusting
Edit: Wow. Tankies are mad. Lmao
Well yeah? The only countries accusing China of mishandling the ETIM in Xinjiang (an issue created by the US through Afganistan btw) are the ones committing an actual genocide in Palestine, i.e imperial core countries. The Organization of Islamic Cooperation, Global South and Muslim countries in general are against the western propaganda about it.
Yeah, because the West is also committing a genocide, that means your genocide is ok. Both are doing genocides. Torturing and raping hundreds if thousands of Uyghurs, forcing them to abandon their culture, forced birth control, forced labour, forced sterilisation and prosecution without any legal process isn’t just combating ETIM terrorists. That’s same level of BS argument Israel is using while flattening entire Gaza and saying they’re only combating Hamas terrorists.
Because they’re corrupt shitheads? They don’t give shit about human rights either, they see more profit from supporting China same way the west sees more profit supporting Israel.
Sources:
And you can’t say Amnesty International is Western propaganda because they’re very critical of Israel and it’s genocide as well.
TIL two wrongs equals a right!
And on .ml you get banned for saying otherwise. Check their modlog.
Yeah, one of the project devs threatened to ban me after I told him to get past his own ego.
Par for the course. I hope for them they don’t break the ethics clauses of their financing.
You’re being dense, the reason is devs get burned out and you’re asking them to do work for free.
The reason that an open source developer might experience burnout are myriad, but can include:
As someone who has done Community Management for an open source, decentralized communication platform (Diaspora), I am familiar with all of these things. This shit is hard, and I am not denying that Lemmy devs have done a lot of good work.
The problem is actually much simpler than you’re making it out to be. For a social platform, which depends on interconnected self-hosted communities to succeed, you absolutely have to build in the tools and utilities necessary to deal with all the crazy shit that comes with the territory. Ignoring this causes a cascade of problems that gradually get worse the longer they remain unaddressed.
The devs are surviving on crowdfunding and grants, and doing the best they can with that. That’s commendable! They probably need more of both to have their needs fully covered. But don’t get it twisted: receiving proceeds for your work is not the same thing as working for free.
Accepting donations is not the same as entering into a contract agreement where the person giving a few bucks per month entitles them to dictate how the work should be done. If people want to enter in a relationship where they get exactly what they want for the money they are giving, then they will be better off by going to a commercial provider, so that the nature of the transaction is explicit and mutually agreed.
About the grants: AFAIK they got the grant to make federation work, which was completed to everyone’s satisfaction. If they had received a big grant from NLNet, got the money but didn’t deliver on what they promised on the application, then you could argue that they did not hold their end of the bargain. But do you it’s fair that because they got money from one part of the work that they should be responsible for all subsequent deliveries?
I’m really trying to understand where you are coming from with this. You mentioned your work on Diaspora, and I don’t know how much you were involved on it, but I do feel that one of the things that doomed Diaspora was that the founders mistook the attention and money they got in 2010 as an indication that they were all alone responsible in “saving us from Facebook”. If Ilya had learned to say “it’s not my responsibility to build everything to win a fight against a multi-billion corporation”, perhaps he would still be around.
With respect, this is a framing issue and depends on your point of view. Does a donation mean someone contracted you to do something specifically? Not really. But, will mismanagement of expectations and hostility convince someone to stop donating to a project? You’d better believe it. If you’re working full-time on a project, donations are your lifeblood. They literally put food on your table. You literally can’t afford to disregard the needs of users and admins. But of course, you are at discretion to decide what those needs actually are, and how critical they are. Nevertheless, the relationship is more transactional than it appears to be.
Overall, I think their grant from NLNet was a good thing, and I think they did good work on that. As long as their work was in scope of the grant, I don’t see a problem with that.
Community Manager, circa 2011 to 2013. I was basically an air traffic controller for GitHub issues, acted as a developer liaison, served as a face of the project to the community, and engaged on the network every single day to get a pulse on what was going on. A lot of it involved smoothing things over with people who were upset about things, resolving conflicts, drumming up volunteer coders, and indicating to core team what varying needs were across the user and developer communities. I lived and breathed it every day.
This is somewhat inaccurate, and here’s why: Diaspora never advertised itself as an Anti-Facebook. They were building a federated network that focused on user freedom, and it was a combination of timing and insanely good luck that their Kickstarter campaign picked up as much as it did. The whole “we’re going to save you from Facebook” thing was an invention of the media to get people to click headlines. What really doomed Diaspora was that the core team wanted to be a startup, the community wanted it to be a project, and getting the company into yCombinator had the team focus on things further and further away from their original goals.
This is where we fundamentally disagree. This is only true if the developers puts the project above themselves, which is the wrong attitude on multiple levels. Developer owe nothing to those donating, they owe nothing to the project and they should never be compelled to accept anything because other people are putting a metaphorical gun to their heads.
And like I said before, even successful projects are barely getting by with donations they are getting. Instead of putting themselves on some imaginary treadmill (one more feature, and we will get people to like us!) it is healthier for everyone if we dropped the pretense that “community is enough” and established beforehand what all parties want to get in order to get something done.
So, here’s the thing: these guys are working full-time on the project. Their only source of income, grants aside, are donations via fundraising. Effectively, they are putting the project above themselves.
The common model for this nowadays is the Patreon / OpenCollective / LiberaPay, where donations are usually given continuously over an indefinite period. It’s closer in form to crowdfunding than it is traditional institutional donations.
This is going to sound shitty: just as the expectation is set that no one should make demands of work done for free, so too is the expectation that development work technically isn’t owed a single penny. Any donor can stop giving, for any reason, at any time.
If I as a donor feel my needs aren’t being met, I can stop donating. As a collective action, a bunch of dissatisfied supporters can do the same all at once.
I’m not saying either side should threaten each other. But let’s not pretend that this is some hoity-toity Utopian model where donors selflessly hand over money with no expectations, and the developer just works on whatever. If your livelihood depends on it, if you can’t put bread on your table without it, then you’ve got to keep your backers happy.
No. They are working on something according to their own terms and their own value scales. They are giving a clear indication of what they are willing to do for the miser amount of money they are getting, and are telling quite clearly what they do not value highly enough to justify spending their time on it.
They would be sacrificing themselves only if they bent over and worked on something they already said they don’t want just because other people see value in the work they already done and want them to keep pushing out the missing functionality.
It sounds shitty because it is shitty. The donation-based model is insufficient and unsustainable. What you are describing is the main reason that I’d rather shut down any of the communick instances over turning to “donation-based” access. At the same time, the reason that I have managed to keep things running (even if not profitable) is that by refusing to play this game I don’t put myself in an unsustainable situation.
The surprising thing is to see how even people who have been involved in the space for so long continue to advocate for the donation-based model. Perhaps it would help everyone if we accepted reality and started telling people that it is not okay to push people to work for free? That donations are only a way to show support for what people are doing and do not entitled them to make demands of any kind? Thay if you want something done according to your exact preference and expectations you need to enter a proper contract where both parties agree to the terms?
This is why I was a bit frustrated with your last blog post. You acknowledge that there is a problem with FOSS development, but instead of trying to elaborate on a alternative model, it went down the route of victim-blaming the FOSS developers who you think should swallow the opportunity cost and keeping cranking out code. This is not healthy at all.
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
Yeah same. I’ve been looking forward to sublinks for quite a while now. I’m jumping to it as soon as it’s ready
What is sublinks?
Update: there was a link in the article, thanks though!
https://sublinks.org/
Yeah, I’m pretty excited about it. Apparently the Pangora (Lemmy fork) dev joined forces, and the new UI is starting to look great.
https://bytes.programming.dev/notes/9qi6rc2avj3gn9dx
I can’t wait to migrate from Lemmy to it. Looks good and all Apps should be working with it
Followed Sublinks on Mastodon for updates 😼
Java is horrible. And Lemmy is open source. We could just fork it and have the best of both worlds.
The core issue here is that there are too many things to do, and too few developers to do them. By the way, for a huge number of these things that need to be done, there is most likely at least one person who thinks it’s the absolute highest priority for Lemmy. Forking would not help fix this issue, it would only make it worse.
In other words: if you’re a Rust dev, you can just fix it in Lemmy anyway, so there is no benefit from forking. If you’re not a Rust dev, then after forking, you will have a new repo to create issues on, except you’ll have 0 devs to actually fix them.