Conversation

Notices

Embed this notice
Blake Leonard (blake@infosec.town)'s status on Tuesday, 03-Oct-2023 05:55:32 JST Blake Leonard

This is starting to sound familiarI think if an XMPP server (in the relevant space) had implemented an API inspired by, say, Discord, the whole ecosystem would be seeing a lot more traction right now. The underlying tech is impossibly confusing and incredibly inconsistent, much like the ActivityPub situation (although AP is still way easier to work with than XMPP). Unlike AP, that inconsistency has made using it in most situations difficult enough that Matrix -- Matrix! -- is a better option (you can start by looking at encryption mechanisms! Ad-hoc commands support!). The saving grace for AP was probably Mastodon, which had real traction even before Twitter imploded, because it worked, it worked well, and it was easy to use from every angle. That's why there are so many good Mastodon clients and bots out there and like one "good" XMPP client that's only available on one platform.

RE: https://infosec.town/notes/9kcv8qx2dq34kdo7
In conversation about a year ago from infosec.town permalink
Attachments
1. Domain not in remote thumbnail source whitelist: media.infosec.town
  
  Blake Leonard (@blake)
  
  @evan@cosocial.ca I think a lot of this is the complexity of it on both sides. Clients and bots sprung up like crazy on Mastodon primarily because of Mastodon's easy, opinionated API (which is also why it's been added to so many other servers, like Firefish and Pleroma). The AP C2S API doesn't have any opinions on how you use it, which is both a blessing and a curse: it's super powerful, but a challenge to work with, especially consistently. Both the client and federation APIs have inconsistent forms and the contexts are weird, i.e. a spec-valid format may fail to parse correctly on any given server or app. JSON-LD tooling isn't used as widely as you'd expect for this, it's usually "just" a super convoluted parsing framework (and JSON-LD support in languages is sparse. This is beginning to sound familiar). There are also a few critical things missing from the API as specified, namely collections for, say, all public/local posts or conversations that you're in. FedBOX has custom endpoints to handle this, which just grab everything it knows about. I'm planning on a different approach for my own server, using AP C2S for sending messages and updating yourself, and a supplementary REST API for getting conversations, determining who you are, and performing proxied lookups (handling the HTTP signatures at the server side, leveraging the database, and allowing for things like `xmpp:` URIs).
- Embed this notice
  infinite love ⴳ (trwnh@mastodon.social)'s status on Tuesday, 03-Oct-2023 07:23:39 JST infinite love ⴳ
  in reply to
  - 受不了包
  @blake @shibao anyway shibs there was a decision to recommend that one should not include an id in cases where one doesn't have the original id. so misskey using local ids for remote follows is something they should not be doing. although i maintain that pleroma also should not check the inner ids if they dont matter anyway. but my real position is that we shouldnt be sending Reject Follow or Undo Accept Follow at all, we should send Remove from followers. maybe a bit late for that though...
  
  In conversation about a year ago permalink
- Embed this notice
  infinite love ⴳ (trwnh@mastodon.social)'s status on Tuesday, 03-Oct-2023 07:23:40 JST infinite love ⴳ
  in reply to
  - 受不了包
  @blake @shibao mastodon can handle it i think, but several other impls don't seem want to even consider it, which is a shame because that means you have to be aware of every single extension beforehand on the consuming side, plus on the producing side you end up having to maintain separate representations if you want to support both as2 and also generic ld. basically the issue is as2 supremacy
  there's other issues with extensibility too, stuff even masto gets wrong, i'm making a list of it all
  
  In conversation about a year ago permalink
- Embed this notice
  infinite love ⴳ (trwnh@mastodon.social)'s status on Tuesday, 03-Oct-2023 07:23:42 JST infinite love ⴳ
  in reply to
  - 受不了包
  @blake @shibao i feel like im missing context here on what i'm supposed to be baited into
  
  In conversation about a year ago permalink
- Embed this notice
  Blake Leonard (blake@infosec.town)'s status on Tuesday, 03-Oct-2023 07:23:42 JST Blake Leonard
  in reply to
  - 受不了包
  - infinite love ⴳ
  @trwnh@mastodon.social @shibao@misskey.bubbletea.dev My reply came from a conversation earlier where someone told me that the "type": ["Note", "extension:Type"] syntax, which is valid according to the spec, isn't widely supported. Sorry for the confusion.
  
  In conversation about a year ago permalink
- Embed this notice
  Blake Leonard (blake@infosec.town)'s status on Tuesday, 03-Oct-2023 07:23:44 JST Blake Leonard
  - 受不了包
  - infinite love ⴳ
  @shibao@misskey.bubbletea.dev @trwnh@mastodon.social Ooh or what about type extensibility? Basic part of the spec but does anyone support it? It's a complete mystery!
  
  In conversation about a year ago permalink
- Embed this notice
  infinite love ⴳ (trwnh@mastodon.social)'s status on Tuesday, 03-Oct-2023 07:27:09 JST infinite love ⴳ
  - 受不了包
  @shibao @blake by evan and everyone else who was there during issue triage i guess
  anyway you assign an id to the local activity which is the outermost one
  you shouldn't assign an id to the inner Follow because it has a remote origin
  
  In conversation about a year ago permalink

Public

Conversation

Notices

Feeds