ActivityPub integration

[Doomsdayrs]

Long shot idea for anyone who wants to try and implement this.

Since MiiVerse is an activity based platform, it would work super well with ActivityPub!

[jonbarrow]

@CaramelKat has already toyed with a read-only integration of ActivityPub for Juxtaposition, making it viewable in existing clients. Due to technical limitations I doubt we would ever be able to expand this in a way that allowed for writing any sort of data (adding "yeahs", making posts, replies, etc.) as we wouldn't really have a good way to reliably link a user back to a PNID on our end

[Doomsdayrs]

@CaramelKat has already toyed with a read-only integration of ActivityPub for Juxtaposition, making it viewable in existing clients. Due to technical limitations I doubt we would ever be able to expand this in a way that allowed for writing any sort of data (adding "yeahs", making posts, replies, etc.) as we wouldn't really have a good way to reliably link a user back to a PNID on our end

For writing data, a hacky silly way of doing it would be to have am "ActivityPub" account that transliterates all the messages.

So @ActivityPub would serve as a broker.

AP -> MiiVerse A post or reply could be formatted

@user@ap.server says:
Wow how cool!

MiiVerse -> AP This is normal

[jonbarrow]

A system like that is easily abusable and would require additional processing when doing actions such as making posts and replies (since we would have to do things like filter out attachments, truncate messages, deal with markdown formatting, etc)

Without a way to reliably link a user back to a PNID this would easily be abused by people who otherwise should not have access to Juxt at all, like banned users

[Doomsdayrs]

A system like that is easily abusable and would require additional processing when doing actions such as making posts and replies (since we would have to do things like filter out attachments, truncate messages, deal with markdown formatting, etc)

I believe that many AP events already send formatted HTML, and dealing with attachments is as simple as not fetching them? It is not like they are sending the image in a binary blob with the AP event (if memory serves me correctly)

Without a way to reliably link a user back to a PNID this would easily be abused by people who otherwise should not have access to Juxt at all, like banned users

To prevent abuse, the incoming AP feature can instead be separate from the main software, along with moderation tools as expected with AP Software such as: Blocklists for servers, Sending reports to other AP powered software, etc.

In the absolute case, the service can be whitelist incoming only, allowing trusted AP servers to be able to send events.

---

For PNID binding, that would be a separate feature. One way is via verification: OwnCast allows a user to "verify" with an AP Account.

[jonbarrow]

I believe that many AP events already send formatted HTML, and dealing with attachments is as simple as not fetching them? It is not like they are sending the image in a binary blob with the AP event (if memory serves me correctly)

That's even more processing then. We don't store message content as HTML, it's stored as plaintext. Storing it as HTML would break viewing it in games, and trying to extract plain text from formatted HTML is just annoying and hacky and error prone

To prevent abuse, the incoming AP feature can instead be separate from the main software, along with moderation tools as expected with AP Software such as: Blocklists for servers, Sending reports to other AP powered software, etc.

In the absolute case, the service can be whitelist incoming only, allowing trusted AP servers to be able to send events.

This just majorly over complicates things, and isn't something I'm personally interested in spending time to implement and maintain

Read-only is good enough, imo.