Tonight at Show Us Your Screens: @liaizon making the case for ⁂ (the character known as asterism) as the Fediverse symbol. Perspective projection distortion courtesy of my phone :)
@russell@hongminhee There's no standard because different cultures do this differently. First+last names in their current Western form are a recent invention, going back a few hundred years max, introduced by early modern bureaucracies. Where dual names were/are used elsewhere, they follow different, varying cultural conventions.
It's not entirely far-fetched to say first name/last name is a vestige of European colonialism.
Is this the time to launch a new botsinspace, based not on Mastodon code but something like #fedify, or even RSS Parrot's minimal Go codebase? A specialized service might be more affordable to operate?
But expertise is clearly needed to detect and block bandwidth-hungry scrapers and other bandits... This needs to be a team effort.
@hongminhee I think JS/TS really is a very widely understood language. My take is that your limited energy is better spent documenting, improving and maintaining a single system, and making that very accessible.
I look at Fedify as an independent "reference implementation" and I have no trouble checking its behavior and source even if I'm building something in a different language/framework.
@hongminhee Hmmm, that's right! In that case though, you'd need a whole regime of keeping that info up-to-date (why couldn't keys change?), and also you cannot serve a request from an actor you haven't seen before... This sounds like a mess :(((
(This is where the pragmatist in me would most definitely take drastic shortcuts and just say, works with the keyId schemas I've seen so far, and I'll just add new ones as they show up in the wild...)
@hongminhee In RSS Parrot I first just took the part before #main-key to be the actor URL. That failed with GoToSocial because it actually uses /main-key.
I ended up parsing the activity before checking they key, and retrieving the actor URL from there. Then I retrieve the actor, which includes the key.
I check that the actor URL is a prefix of the key ID from the signature.
@hongminhee It's still an assumption that actor URL is a prefix of the key ID, but it works with the systems I'm seeing.
I haven't found any clear requirement about this in the AP specs.
I'm a little unhappy about parsing the message content before verifying the signature b/c it messes up the logical order of things, and because I'm not sure if it entails any security risk. (But I'm skeptical about the HTTPsig approach as a whole so it adds little extra doubt.)
@hongminhee This is awesome! I can see how this can snowball into a huge effort if you cover all the different entities around, and their properties.
It's also very, very useful! It'd fill the gaps that the official spec leaves undocumented.
It'd be super useful to include what type of data can occur in different fields. E.g. in a Note I've seen cc as omitted, null, a string, or a list of strings.
@clacke I need more context here... I don't entirely understand the ask. Can you drop an email, or open an issue on Github? I'll be happy to look into it and implement any tweaks that improve folks' experience with the Parrot. Thanks!
@tchambers@birb Hmmmm, I didn't explicitly test those, but they should work out of the box? Do you have an example link where you're not getting what you expect?
Under-the-radar late night launch: RSS Parrot is live! It talks like Mastodon, but it doesn't walk like Mastodon. BUT! It will relay any RSS feed straight into your timeline.
Turn Mastodon into your very own feed reader. Follow anything that has an RSS feed and get a toot about new posts.
How? Mention @birb with the address you want to follow.