I’m not sure, either.

I can imagine, though, that if Lemmy automatically inserted the original post author in replies as a Mention, it would be indistinguishable from when it’s done manually to page another user. So if you made a post as a Lemmy user, every reply in the comment chain would show up in your Notifications.

You and db0 are doing different things - he has blog that Lemmy users can interact with as if it was another Lemmy community, whereas you have a blog that you want to use to post articles into a different Lemmy community.

A reply is sent from Lemmy twice - once to the community to Announce out to its followers, and once to the person being replied to. A top-level reply will appear on the WordPress blog because it is a reply to the author. A reply to a reply won’t, because the blog is not following the Lemmy community (so won’t get the Announce), and the author isn’t the person being replied to.

If you want a reply to a reply to also appear on WordPress, you need to treat it like Mastodon, and also Mention the original author. Here is an example that also appeared on the blog: https://lemmy.world/comment/14897939 (the reply from ‘freamon’)

TootSweet’s link was to a migration. A migration is used to upgrade a database’s schema - changing the limit on username length from whatever it was, to 255. As it happens, it’s still 255 now, but an upgrade from 3 years ago isn’t a good source for that, because as they themselves said, there could very well have been been upgrades since, that further changed the limit.

I used ‘unscientific’ because it would be a pain in the arse for someone else to reproduce, it only applies to one instance, it’s a test on someone else’s in-production system that you have no control over, and the error that returns isn’t necessarily from the backend. It looks more like a Form Validation error (i.e. from the frontend). It’s perfectly possible to create a frontend that puts it’s own limits on username length, and there’s some that no doubt already exist, so a brute-force test of those limits isn’t telling you anything reliable about what Lemmy’s internal limits are.

I think the way you were using references started to wind me up. It gave some academic veneer to a format that usually more conversational. They’re just links to what some people reckon, but dressed up with ‘accessed’ and ‘published’ in a footnote format that in other other contexts would suggest a level of credibility that they don’t have. Either something is solved or it isn’t, but it shouldn’t be marked ‘solved’ with links to answers of questionable accuracy.

Is it? Maybe. If I was using software, and asked a question that the developers of it could easily answer, and they didn’t, I might think about using something else. It certainly would’ve helped though, if you’d got an answer from someone you were more ready to believe.

I think you can be an outsider to a particular system, and still be able to provide valuable information about it. Enough to be able to satisfy your own curiosity, and hopefully someone else’s too. I can imagine a version of this post where you asked what the max username length was, I gave you a means to find out, and we both went on our way. So you can be ‘right person’ to comment on a post, but the ‘wrong person’ when it turns out that your answer isn’t going to be fully accepted without digging into someone else’s source code. As for who the right person is in that case, there’s some overlap with your comment about ‘entitlement’, so I’ll continue there.

I saw your edit, yeah. I’m not some precious person who thinks no-one should dare question their claims. To my mind, though, what I said wasn’t a claim. A claim would be if I’d said “lemmy.world is 26, sh.itjustworks is 50” with no further info. Instead, I gave command-line instructions for you to run yourself, so you could get the answers for those instances (and any other instances) from Lemmy’s backend itself. If I wasn’t reasonably sure that the backend was giving you the numbers you were looking for, I wouldn’t have mentioned it.

I wasn’t reacting to being questioned, though, I was reacting to being singled-out for being questioned. You marked this as “Solved” based - also - on a test from you, and an answer from TootSweet, but it didn’t look like to me that you ever questioned whether those answers deserved a follow-up. Neither of those, in my opinion, are really good enough, but I’ll say why in the answers to your individual comments about them.

I’m not used to this level of rigour to be honest. You’ve accepted your own unscientific prodding of one particular instance as an answer, and one link to a years-old migration as a answer, but I give you reproducible command-line instructions, which match up with your own findings, and it’s apparently not good enough.

Anyway, as that migration shows, Lemmy distinguishes between ‘name’ for username, and ‘display_name’ for the display name. A better link for this is arguably https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/schema.rs#L735 but whatever. It’s these fields that are relevant to Lemmy’s API, not the terminology that ActivityPub uses. A client might reasonably want to know the limit for a username (as provided in the Site response), because it’s this that’s used for Signup and Login. Display name is set elsewhere, once that’s done, so it doesn’t make sense for actor_name_max_length to refer to this.

Within ActivityPub, the distinction between username and display name is ‘preferredUsername’ and ‘name’, but AP also uses ‘name’ for a bunch of other things (including but not limited to what becomes a post title, a choice in a poll, or the alt-text for an image). There’s some overlap with how Lemmy’s API refers to stuff (e.g. a post title is a post name), but it not a 1:1 match.

I hope this is enough. I don’t even use Lemmy, so - in my opinion - you’re asking the wrong question to the wrong person. What you should be asking, is - “How come when I post a question to Lemmy’s support community, on the instance owned by Lemmy devs, it looks like they just ignore it?”. You shouldn’t have to be relying on guesswork by amateurs, irrespective of how many ‘references’ they can quote.

Not much. I think Lemmy’s current API docs are generated from the JS client. So I guess there’s

https://join-lemmy.org/lemmy-js-client-docs/v0.19/interfaces/LocalSite.html#actor_name_max_length

This refers to the wrong line number though, it’s actually at:

https://github.com/LemmyNet/lemmy-js-client/blob/ad9f402e06292899a35927c46fe48b22c6f5eb27/src/types/LocalSite.ts#L59

It seems to be set per-instance - you can find out through their APIs:

curl -L http://lemmy.world/api/v3/site | jq -r .site_view.local_site.actor_name_max_length (26)

curl -L http://sh.itjust.works/api/v3/site | jq -r .site_view.local_site.actor_name_max_length (50)

It uses postgres for the DB - I think that and redis are designed to operate at very large scales, so it wouldn’t be them.

My guess would be that it’s something in the interpreted nature of Python - this seems to be why a familiar dismissal of PieFed is a concern about how it will scale.

That said, this site shows that Python is the most popular language for Fediverse apps (just), the likes of Mastodon are written in another interpreted language (Ruby), and I think there are more big websites running Python (with Django or Flask) than people realise. So I don’t know, really, I’m just following other people’s lead on this. I don’t imagine that any problems would be insurmountable though: an admin could restrict the amount of signups, or if new users mean a few more donations, they could just throw money at the problem (more cycles for one server, or splitting up tasks across multiple servers).

In terms of incoming federation, PieFed sites are dealing with as much activity as any general Lemmy instance. It’s not happened yet, but I suppose it’s possible that problems will become apparent if the amount of local users gets over a certain size. A limit on the amount of users per instance isn’t necessarily a bad thing though (it’s cheap, and hopefully easy enough, for someone to spin up another one).

This is all quite old drama, and the issue itself is fixed now, but at one point someone kicked off about how if you uploaded a picture to Lemmy, there was no easy way to delete it (you could delete your post, but the image would still be there at whatever URL was created for it, and it wasn’t even that easy for admins to find and remove it) - so I’m guessing that it stems from that.

Oh yeah, sorry. I didn’t mention that the API isn’t available on production sites like piefed.social. I’ve been messing around with a build of Thunder on my dev instance, and - among other things - the app doesn’t uses the same V3 endpoint that Lemmy does, so it’d always need to be a different version than the one that’s currently available for Lemmy.

No, it’s not geared up for that. There’s a platform called sublinks where the intention is to be initially compatible enough with Lemmy that it can be a drop-in replacement, but they haven’t released anything yet.

It’s not so much that we expect the developers of Lemmy apps to retool. The hope is that, if we can provide a sensible, well-documented API, then it will appeal to front-end developers looking for a project. Also, if there are any devs of Lemmy mobile apps who are unhappy with Lemmy’s API for any reason, then getting involved with PieFed’s whilst it’s still in development, offers them a chance to shape one to their desires.

Speaking of Thunder though - I’ve been able to compile it for desktop, and get it working with PieFed’s API in the state it’s in now. I’ve no experience with Flutter / Dart or front-end development, so it suggests that - for open source Lemmy apps, at least - it doesn’t need to be the original author who ports it, and that the actual details a particular API are only a relatively small part of creating a good mobile app.

Hypothetically, sure: the info exists in one place - they’d just have to arrange a way to transfer it.

Votes themselves are a simple activity, but each one can cause a surprising increase in storage requirements (every vote has a user, every user has an instance, every instance has admins, and all these entities might have avatar and banner images associated with them). Most instances are run by one person as a hobby, and paying for DB and image storage seems to be the no. 1 reason for instances folding, so there’s generally a question of how much one instance should be an exact mirror of another one.

You’re correct in assuming that nothing is stuck in a queue.

Compared with other Fediverse platforms, a feature that Lemmy lacks is paginated outboxes. These would allow communities to list all the posts, because other instances could get them a page at a time (e.g. 20 for page 1, then the next 20 for page 2, and so on). Instead, they provide a non-paginated outbox with only the most recent 50 posts. An outbox for comments isn’t really feasible without pagination, which is probably why they don’t provide one at all. For votes, it’s even less practical, and irrespective of that, it would go against the familiar hang-up about votes being private.

So if you’re the first person to join a remote community, then 50 recent posts are brought in, but no older posts, no comments, and no votes. There’s no way to get the old votes. If your instance receives some activity that makes it realise that it’s missing something, then it will resolve it (e.g. it will often fetch an old post if it receives a reply to it, and fetch a comment if it receives a vote for it), but it will start that post or comment at score 0.

If you really wanted to be fully in-sync for comments, then you could script it to use the APIs for the remote and local instance. For the remote instance it would be something like: list the posts oldest to newest (limited by the amount you’re missing); get the ap_id for each one, then login to your instance and ask it to resolve it. Then do the same for the comments in each post. Everything it resolves would be a score 0 though, and it assumes that the author hasn’t deleted themselves in the meantime, or that their instance hasn’t disappeared. Given that, I don’t really see the point, other than trying to a completist about stuff.

MBIN makes upvotes visible, but PieFed doesn’t. The thread you linked to is about PieFed anonymising votes, so they aren’t revealed on instances like MBIN.