Another commenter (who's contributed code to Lemmy) pointed to a link that provides the specification for that field: "A simple, human-readable, plain-text name for the object. HTML markup MUST NOT be included."
So in this case, it's more that the JSON looks a bit ambiguous: 'mediaType' is only referring to the format of the text in a post's body, but - unlike me - you'd also need to be aware of the spec to know that it doesn't apply to the title.
For clarity, I wasn't intending to say that PieFed treats that field as HTML (it treats it as text), I just meant that if you were looking at that JSON, and being a bit lazy like me and not looking at specs, then it wouldn't be unreasonable to assume that the 'mediaType' field also refers to 'name' (rather than a 'content' field which this post doesn't happen to have).
Anyway, this seems to be even more reason why MD shouldn't be put in titles, and front-ends shouldn't be encouraging the practise by rendering it.
You can, but maybe you shouldn't. Given that this post is in the fediverse community, I don't feel too bad about mentioning that Lemmy is part of a federated network with PieFed and MBIN (I try not to bollock on too much about the platform I happen to be using).
In the ActivityPub JSON for this post, there is no indication that this field contains MarkDown. If anything, it says the opposite, it says it contains HTML. It's therefore not unreasonable for other platforms to render it as such.
Given this, and the poor support for mobile clients indicated in the comments, and the fact that it's only a subset of MarkDown tags, but include ones that aren't part of CommonMark standard, I'd argue that it's not necessarily a good idea.
I don't see how. Perhaps someone more knowledgeable than me will answer, but - generally speaking - you don't want a page you're viewing to be doing live queries of completely external resources, for instances that might be down, or timeout, or need another query because they need a signed GET request instead of an unsigned one. It's not usual for accounts to be following 1000s of other other users, so you'd be sat in front of a spinning wheel, not knowing what's going on, and not knowing when it's going to finish.
Another user replied to me to say that once you've pasted your handle into that box once for one user, it's already pre-filled for the next one, so that reduces the burden a bit.
Oh, I thought I had explained it. You can't follow those users directly because your instance doesn't already know about them. It's not going to do a bunch of outgoing requests, and add the details for a bunch of people to its database, to generate a list of them for you to possibly ignore. Those people would have made posts, but that's irrelevant if your instance hasn't seen them.
Copying my handle, and then pasting it into a box when visiting an account on its home instance doesn't seem like a massive obstruction to me. Do that, and your instance becomes aware of those users, and of other users when they boost something, and your instance becomes more intermeshed with all the others, and the original problem is much less of one.
If you're on a small instance, then you have a lot of influence in how connected it is to others, but you have to do the work.
I tried this out. I have an account on defcon.social and follow nixCraft@mastodon.social. If I click on that name, it says '153 following' but if I click on that, it only brings up 1 of them. This is because it's only going to list the users that defcon.social is already aware of, and isn't going to bring in the details of 100s of other users on the off-chance I might want to follow them. For that 1 user though, it did give me a link to follow them (I use the phanpy app).
For what you want to do, I'd have had to visit the account at mastodon.social, click 'following' and then be prepared to enter my own details in the box that comes up when I press 'follow' for each relevant person.
OP won't see your image unfortunately, because of a difference in how embeds are handled (Mastodon's use of image attachments to Lemmy's use of MarkDown has been fixed in one direction, but not the other).
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).
jointhefediverse.net - Why was Lemmy removed from the list of fediverse alternatives?
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).
What's unclaimsies and how badly does it break the lore?
Skeleton Crew is set in the world of children as much as it's set in the world of Star Wars, and is concerned as much with pirate lore as it is Star Wars lore. "Claimsies" and "unclaimsies" is just "finders, keepers!" and another child's attempt to reverse that.
There's a key moment in the show where it combines those two concepts - the made-up words and rules of children, with the made-up words and rules of pirates -
A droid decides that a call of "unclaimsies" is "close-enough" to pirate lore that it will let them re-take a ship that's been commandeered by a pirate.
It's all very delightful.
jointhefediverse.net - Why was Lemmy removed from the list of fediverse alternatives?
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.
jointhefediverse.net - Why was Lemmy removed from the list of fediverse alternatives?
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.
jointhefediverse.net - Why was Lemmy removed from the list of fediverse alternatives?
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.
jointhefediverse.net - Why was Lemmy removed from the list of fediverse alternatives?
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.
As Admiral Pat mentions, embeds are easy enough. I don't know how Tesseract does it, but a low-tech solution is to just replace 'watch' in the URL with 'embed' and stick it in a iframe. From Lemmy's GitHub, it looks like there's been work on this, but I'm not familiar enough with it to know whether it's for future versions that haven't been released yet.
New videos used to come in to Lemmy as expected. There's been some regression that stopped it. It's possible to bring them in manually though (by searching for the URL), and - like with embeds - it's possible that it's been fixed but not yet released.
PT's videos channels are ActivityPub Group types like Lemmy's communities, but it doesn't handle federation the same way. It does it in a way that's more compatible with Mastodon. Lemmy's communities Announce everything they receive (posts, comments, votes, etc) and so if you receive that Announce, then as long as you trust the community, you can trust that the contents haven't been changed and process it. PT's video channels only Announce new posts (so on Mastodon, it appears as if the channel has Boosted content by the channel owner), but for everything else, it's a combination of sending out a 'post update' (which is essentially an invitation to query the outboxes it provides for votes and comments), and just flinging out the comment as is, without the HTTP signature. If you get that comment, then you can either use the LD signature that Mastodon includes to verify, or you can look at the ID, and fetch it from it's source. As such, Lemmy's federation model is mostly Push-based, whereas PeerTube's is a bit of Push, and a lot more Pull.
It depends on what youtube is willing to provide. It seems more likely to provide a thumbnail if you use a youtu.be link than a youtube.com link.
Instances running Lemmy from 0.19.4 onwards (I think) provide the option of providing a separate thumbnail manually, which is useful, but your instance is on 0.19.3.
Yeah. ActivityPub has a type called 'Announce' that's used to make your followers aware of activity by another account. Mastodon uses it only for 'boosting' another user's content, but Lemmy's communities use it for everything ('Andrew has posted this comment', 'Andrew has Liked this post's, etc). Most of Lemmy's activities are ignored by Mastodon, but the Announce of a post or a comment is interpreted as a Boost.
It sort of works as a way to follow a community on Mastodon, but the individual boosting of all comments makes it annoying. I doubt anyone has set up a different account - you should be able to see the details of which actor is doing by clicking on it or hovering your mouse over it.
Anyway, speaking of jokes, have you heard how many MBIN users it takes to screw in a lightbulb?Answer: 10. 1 to screw in the bulb, and 9 to tell you how great the software is. (I'm just kidding - there aren't 10 MBIN users, it just seems like there are because it evidently comes with a massive crowbar used to derail every thread to bollock on about it).
Another commenter (who's contributed code to Lemmy) pointed to a link that provides the specification for that field: "A simple, human-readable, plain-text name for the object. HTML markup MUST NOT be included."
So in this case, it's more that the JSON looks a bit ambiguous: 'mediaType' is only referring to the format of the text in a post's body, but - unlike me - you'd also need to be aware of the spec to know that it doesn't apply to the title.