PriorProject @ PriorProject @lemmy.world

Just an explorer in the threadiverse.

---

Read more

Posts

9

Comments

266

Joined

2 yr. ago

Does anyone know why they don't keep the engine rev'ed off-throttle today to keep the MGU-H spinning? It seems like it should:

• Generate energy by spinning the MGU-H with spare engine power.
• Reduce energy consumption by keeping the turbo spun up while using less energy deployment.
• Turn off-throttle "wasted" engine power into increased peak power on-throttle through energy deployment.

The only explanation I can think of is that they can exceed the per-lap energy deployment limits specified in the rules without doing this so there's no point. In which case I guess what's bringing this back in 2026 is increased per-lap deployment limits.

This leads into my next concern which is GDPR, because now i can't be certain that a users data gets deleted upon their request and i'm not certain whether i would be liable since my instance federates with the malicious instance (which may also not be hosted in the EU which is itself problematic, and even if i'm not liable it's still not great).

I'm not a lawyer, but I have done compliance work, but not for GPDR... so take with several grains of salt.

I'd be fairly surprised if other instances caching your data had any impact on your GPDR status (unless you wrongfully made that data public in the first place).

If WordPress.com hosts an intentionally public blog post for a user, and archive.org scrapes it and saves a copy, and the user deletes it from WordPress (which correctly handles the deletion), would GPDR hold WordPress liable for a different organization retaining a copy on a different server? It would surprise me if it did, I can't imagine how anyone could be in compliance while hosting public content under any circumstances if that were so. ActivityPub is not exactly the same as this, as it automates the process of copying data to many servers. But so does RSS and that's not new. If this were an issue, I think we'd have seen examples of it before now.

It's more likely that each ActivityPub instance is a different service from GPDR's perspective, and each instance needs the capability to delete content associated with a user upon request. But I believe deletes are already federated by default, so we're only talking about malicious instances that deliberately ignore deletion requests. These would not be GPDR compliant, but I suspect that doesn't reflect on your liability.

... which may also not be hosted in the EU which is itself problematic...

Data locality is an interesting question, but I'm again inclined to suspect that YOU are not hosting data outside the EU. Other instances are, and the liability for doing so is theirs not yours.

If you were concerned about this, you could do whitelist federation where you explicitly add instances in appropriate jurisdictions rather than Federating by default with a blacklist. The opportunity cost of doing this is, of course, cultural irrelevance. You'd be cutting yourself off from most of the physical and virtual world in order to achieve improved data locality.

The loss of control over content is also something that i don't particularly like...

This is real but rather the point of federation. If you really don't like it, then federation is not for you. But consider multiple perspectives:

• As a user of reddit or another centralized publishing platform, you already didn't have control over your data. The hoster did, as did the untold millions who scraped it maliciously and silently. This does not compare favorably to the fediverse.
• As an admin of a traditional forum like PHPBB, you do give up control in the Fediverse. Though when you account for malicious scrapers, how much you give up is debatable.
• But as a user of that PHPBB forum, the fediverse gives you MORE control. If the admin of that non-federated forum throws a tantrum and shuts it down, the community and posts are lost. As a user in the Fediverse, federation allows users on other instances to retain their account identity, recover posts from caches, and re-establish their community elsewhere against the wishes of the previous hoster.

Federation does require the hoster to give up power, but more than equally increases the power of users in return. Like GPDR, federation aims at increasing the data autonomy of users, but rather than focusing on privacy and data destruction to facilitate a user who wants to take their toys and go home, it focuses on how users can continue to access their data usefully in the face of an admin who want to take their toys and go home. Although the means to achieve them are often in conflict... control over data destruction and control over data preservation are two sides of the same data-autonomy coin.

Federated replication load scales with the number of instances multiplied by the number of communities they subscribe to.

That's a hasty generalization that you just made that up.

Sigh. No. No, that's actually how the computational complexity scales and it's not a difficult analysis to perform. Good luck to you though.

My dude... If you want to contribute, by all means, show us where there is a problem, other than in your imagination, and it will be seriously considered.

I had no idea we were doing condescending pet names, this is a fun game. My sweet summer child...

• Federation ain't doing great.
• Federated replication load scales with the number of instances multiplied by the number of communities they subscribe to.
• Server counts are growing at ~10x per month.
• The defaults of this script encourage single-user instances admins to bump their sub count ~70x from something like 100 communities to something more like 7000 communities.
• Users of this script actually literally don't understand how federation works. They think they're proxying through to the upstream instance while they browse rather than getting firehosed with the entire lemmyverse by they're asleep.

It doesn't take a rocket surgeon to figure out that global federation worker queues are not in great shape, or that a default that encourages single-user instance owners who have no idea what they're doing to bump their sub count 70x isn't helping the situation. If you think this is in my head I can't help you. But I can help others understand that running this script with default settings is an awful and unnecessary idea.

The relevant change is this: https://github.com/jheidecker/lemmony/commit/9b0b7232a1a942615eb67a34f2526328a23fcdd5

It's not meaningful though. It allows one to optionally limit to the top-n communities by active-user count, but the default is still unlimited and the docs still do nothing to explain the abusive load that excessive subscription puts on instances that host communities.

We've been reviewing the data and found that:

• You're braking early going into turns 3 and 9.
• You can downshift more aggressively going into turn 6 for more engine braking.
• And you're only applying 60% of the throttle for most of the pit-lane straight. We think there's a few 10ths in it if you press it the rest of the way down for the whole straight.

Now it's full of people who aren't hosting it and it's not self-hosted for them anymore.

The idea of a self-hosted community is meaningless. It has to attract people other than the hoster to be useful.

Well, it's self-hosting, right. We each host our own server with our own self-hosting community. Alone. No other posters, commenters, or voters. Just each of us in isolation talking to ourselves about our hosting setup.

This is a dumb meme, there's no such thing as self-hosting a community. A community only becomes valuable when you share it beyond the hoster, at which point it stops being self-hosted for most community-members. I believe Ruud did actually create this community, which means it is properly self-hosted as much as a successful community can be.

Username does not check out. This comment is inappropriately clueful.

The linked post dismisses the v0.18.0 upgrade as a possible cause, but appears to do so without evidence and it's by far the most likely explanation.

Whether the fix has to happen on the Lemmy or the kbin side to restore compatibility is an open question, but I don't see any evidence of anything beyond a normal upgrade that broke an untested cross-app interaction.

I posted early on in that sub about merging/coordinating with this one and the mod replied they weren't closing the sub and removed my post. Note there is (or at least was at the time) nothing in the community or instance rules prohibiting discussion of other communities. And also... like... 90% of Lemmy is new users finding new communities (including that mod, whose account was like 4d old at the time). Prohibiting discussion of other communities is just... wildly against the spirit of what's happening right now. Neither mod group seems to acknowledge the other in at-mentions either.

Anyway, it's a small data point but my somewhat speculative take is the mod over there is power tripping and I've avoided it since.

While this one seems more active, the other one has more members (strangely).

The sub numbers can be confusing to read. I believe when viewing the sub count of a remote community, you see only subscribers from your instance... But when viewing a local community you see all subscribers. At any rate, if you look at each community on its home server you see:

• This sub has ~3k subscribers: https://lemmy.ml/c/formula1
• The other has like ~1.5k: https://lemmy.world/c/formula1

I don't know if lemmy supports sub-paths, I've never seen a lemmy hosted at one though. If it doesn't nginx definitely supports vhosts. So a single server/vm/container can definitely respond both at my.host.com and lemmy.host.com with appropriate content.

In lemmy, you subscribe to a "community". Once subscribed...

• You get all future posts and comments posted to that community, you don't get a full historical backfill.
• Posts and comments from users on instances that your instance has defederated with. Like sh.itjust.works has defederated lemmygrad.ml, so you won't see any posts or comments from users with an account registered there even though I'll see both of your posts/comments since my instance federates with both.
• When you first subscribe to a new community that no one else on your server has subbed yet, it can feel weird that the comment history isn't backfilled. You'll see seemingly empty posts that have comments when viewed from other instances. This situation will right itself after a day or two as posts made after you subscribe will have their full comment history replicated to you as they happen. It's just the initial wave of posts that have a weird comment history due to the lack of backfill.

You don't have to follow user accounts at all. I'm not even sure if that's possible, I haven't done it.

This article seems to be from October of last year. Did something happen recently related to this?

What’s the network flow like? I’m posting this to the lemmy.ml /asklemmy community, but I’m composing it on the sh.itjust.works interface. I’m assuming sh.itjust.works hands this over to lemmy.ml. How does my browsing work? Is all of my traffic routed through sh.itjust.works?

• You register your account on sh.itjust.works, that's where all the info you care about resides. Your list of subscribed communities resides there. When you read a post, it gets fetched out of the db on sh.itjust.works (irrespective of where the home instance for that post's community is... when you read it it comes out of the database on your home instance), and when you comment on a post, that gets written to the db on your home instance. Your home instance a standalone fully functioning thing.
• When you subscribe to a remote community like this one, you tell your home instance "keep up to date with posts and comments for this community and let me know about them. Your home instance asynchronously gets all those updates while you're asleep or whatever so it can show them to you out of its local database when you come back. If more users on sh.itjust.works subscribe to the same community... there's no incremental overhead. All ya'lls instance is ALREADY subscribed to that sub. So other users on your instance can sub to it for free, it's already in the instance's database.

Assuming there’s a mass influx of redditors, what does it look like as things fail?

• If lemmy.ml (where this community is homed) falls over from being overloaded or just is broken for whatever reason, your instance is unaffected. You can still read posts and make comments. This community however... is affected. New posts and comments for this community might come through intermitently or not at all for you (and everyone in the lemmyverse) because the community's home server isn't working well enough to reliably deliver them over federated replication. You can still read older posts and comments that have already been synced to your home instance, but new ones might not arrive. You might also see weird stuff like being able to see new comments from other sh.itjust.works users on this community, since those get written to your db before getting federated back to the community's home server. But mostly updates from other instances stop or get unreliable.
• If sh.itjust.works falls over for some reason... well... that sucks for you. You can't log in or browse anything on it. You can still visit this sub at https://lemmy.ml/c/asklemmy/ as long as lemmy.ml is working and you'll be able to see the posts and comments that other accounts make. But you'll be an anonymous read-only browser, you won't be able to post or comment until sh.itjust.works comes back online (or you make a new account elsewhere and lose all your comment history and subscription list).

Are there easy mechanisms to allow me to grab my post history?

There's a github issue for this, but it's not done yet: https://github.com/LemmyNet/lemmy/issues/506.

I’m assuming most (all?) Lemmy servers are hosted in home labs?

I don't think that's a good assumption. lemmy.ml is hosted on OVH, a cloud provider. My home instance on lemmy.world is hosted by admins that run something like a 32 CPU mastodon instance. Most instances with over 100 users are running on some kind of probably modest but "real" cloud instance. The admins are volunteers, but often smart technical folks paying for small but real compute infrastructure.

The idea of Lemmy excites me, but the growth pain that could be coming scares me. Anybody using a CDN in front of their servers? That could be good, but with unconstrained growth, that could be costly, which is very bad.

Anticipating growing pains isn't wrong, it's probably gonna happen. But the devs are gonna find and work on the biggest performance problems so that people can viably run bigger instances, and instance admins are gonna run bigger hardware and ask for donations or run patreons to cover the cost. In my opinion, the bigger worry is that Lemmy will fizzle... not that it will spectacularly explode. As long as people join and contribute and are interested, we'll find a way to improve scalability and performance. The death knell would be if people get bored and leave, but compute capacity won't be the problem in that scenario.

This may be obvious and not what you want to do, but Lemmy's own UI is optimized for threaded conversations within a post. Browsing Lemmy communities from an account on a Lemmy instance looks pretty sensible.

That doesn't help you manage comment toots from Mastodon, but if you don't find another solution... it will look better from Lemmy itself.

Say what you will about reddit, at least an established subreddit was the place to gather on the topic, ie r/technology etc.

This premise on which your question is based isn't actually true though. There's /r/technology and also /r/tech. There's /r/DnD and also /r/dndnext. As of recently, for some reason there are like 35 nearly identical amitheasshole subreddits with different names.

I feel like what you're observing is just that reddit communities are mature, people have had time to gravitate to whichever community is more active or has better quality moderation and so there is generally a "winner" sub with more participation because... unless there's a major problem with the bigger sub it tends to be more interesting than a less well-trafficked sub.

Lemmy, in contrast, is still fairly wild-west. Most communities are not very active and have only a few subscribers. If a competing community with an overlapping topic appears, folks are willing to subscribe to it just in case it takes off. If Lemmy continues to retain a healthy number of users, I expect in most cases that consolidation would set in unless there were major differences in moderation policy or something else that splits the community into factions that align across server or community boundaries... and over time you'll see a similar layout of one or two dominant communities and a long tail of tiny ones that few pay attention to.

I had no idea how new this instance was when I joined it a few days ago. I picked it semi-randomly because it had a low-ish user count but seemed to be associated with mastodon.world, which seems pretty big, so I figured it must have admins behind it that were experienced with biggish federated instances.

I think the difference is one of them auto filters to only communities and one searches for all types...

Yeah, that's true by default. But in both cases, the search results page includes a dropdown of types. The header version defaults to all and the communities version defaults to communities. But they're the same search results page, and you can filter the types however you want on either if you change the value of that dropdown once you arrive at the initial search results.

For what it's worth, as someone participating in communities I'm likely to gravitate toward the most established one irrespective of what instance it's on. If there's a problem with an established community (bad moderation policies, bad moderators, lots of posts I don't like, or whatever) then I'll look for alternatives.

But generally, I'm more interested in more communities covering new and niche topics than I am in local copies of communities that are healthy on another instance.