What does this mean for Lemmy instances and the practice of blocking and banning users and instances?

Nothing at all.

From the text of the bill:

This chapter applies only to a social media platform that functionally has more than 50 million active users in the United States in a calendar month.

Lemmy doesn’t have that many users, and if we’re being honest, probably never will. So this unbelievably stupid and bad law doesn’t apply, and isn’t likely to in the future.

Hopefully it’s struck down, though I wouldn’t count on anything reasonable or logical coming from the ghouls on the Supreme Court these days.

Chat systems aren’t email, or Usenet, or forums, and while it is a good feature in the context of those async / longer-form communication, where you need the context, it doesn’t work nearly as well for realtime chat, where you already have the context because it happened two seconds ago.

The convention of replying in thread or in channel is a combination of personal preference (I like/dislike or am/am not used to threads), group expectations (we have agreed to reply in threads/in channel), and muscle memory (I mostly talk in channels that reply in thread, but this one expects it in channel). As the number of participants increases, it gets hard to manage, so you get a mix of in-thread or in-channel replies (and in-thread replies to in-channel replies), which leads to a fragmented, inconsistent mess and people complaining about both styles at once.

why do they keep making it worse

bye then

In what way have they “taken a back seat?” Taken a back seat to what?

Taken a back seat to browser development.

And in what way does this manifest? They lack features that the web UI has? Why are you bringing it up here instead of filing tickets with mobile apps?

It seems silly to say they’ve “taken a back seat” when they’re entirely different pieces of software written by different individuals. It’s like saying that Chrome development is taking a back seat to DuckDuckGo. They’re different things entirely.

I don’t believe those client apps are built by the same folks as Lemmy…

They aren’t except for ‘jerboa’.

It’s a side project by a Lemmy developer, not an official part of Lemmy.

…therefore whether they “function properly” is purely a concern for their developers and users.

It’s a concern because most users connect to the Internet through mobile apps.

Lemmy is non-commercial and as such “the market” doesn’t work in the same way as an integrated product like Instagram, Twitter, etc.

I’m not addressing the differing world market systems. I’m addressing how most people connect to the Internet.

You seem to have confused and incorrect ideas about how the internet works.

It’s my, general, understanding that most people connect to the Internet through mobile apps.

Certainly, a lot of people use mobile apps.

If this is the case, then why have apps such as Remmel, Lemmur and jerboa taken a back seat?

In what way have they “taken a back seat?” Taken a back seat to what?

They seem to be there for anyone who wants to use them, and look like they’re actively maintained.

IMHO, it would be a mistake to market Lemmy without these mobile apps functioning properly.

I don’t believe those client apps are built by the same folks as Lemmy, therefore whether they “function properly” is purely a concern for their developers and users.

Lemmy is non-commercial and as such “the market” doesn’t work in the same way as an integrated product like Instagram, Twitter, etc.

Funny, I was just the other day appreciating that Lemmy didn’t try to open in a new tab.

Well, I can see that this isn’t going to be a productive conversation, so I’m out.

I’ll just leave you with this: you have two people here who agree that docs need significant work, and I gave a detailed list of specific things that need addressing. Ignoring half the issues to say, essentially, “you’re wrong, just click around” is not helpful.

Several ways:

• They don’t simply describe the API. The description of the API is embedded in a particular (JavaScript) implementation of the API client.
• There are almost no textual descriptions of anything, and the ones that do exist are useless, because all they do is repeat the name of the function. For example, the full documentation for deleteCommunity() is “Delete a community.” In what circumstances may I delete a community? What authentication needs to be performed before this function is called? What response should I expect if the deletion failed?
• The actual payload structs all have almost no documentation. What’s the difference between DeleteCommunity and RemoveCommunity? Okay, so only an admin can remove a community, but like… what do these things actually do?
• There’s no place to see everything about an endpoint: its URL, request/response types, etc. It’s strewn all over the place, making it harder to find. likePost tells you part of the URL, and the method. You have to click through to CreatePostLike to see the shape of the request body, and PostResponse (and then PostView) to see the expected response… but only on success. For errors, I have no idea. I got down into wrapper(), but it looks like it simply may not implement error handling at all. Figuring out the URL is another slog, this time through buildFullUrl() and the constructor.

In short: The API isn’t really documented, and building a new API client requires reverse engineering the JavaScript one.

Before we used to manually maintain other API docs, and it was a huge hassle to keep them updated.

Certainly, writing documentation is work. But the decision to stop doing it externalizes and multiplies the hassle – it shifts from the Lemmy developers needing to maintain documentation once, to any programmer wishing to interact with Lemmy needing to RE the JS client, every time.

Autogenerating Swagger documentation may be one way to reduce the burden on the Lemmy maintainers.