Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] ActivityPub integration #34

Open
Doomsdayrs opened this issue Apr 8, 2024 · 5 comments
Open

[Enhancement] ActivityPub integration #34

Doomsdayrs opened this issue Apr 8, 2024 · 5 comments
Labels
approved The topic is approved by a developer enhancement An update to an existing part of the codebase

Comments

@Doomsdayrs
Copy link

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
Copy link
Member

@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
Copy link
Author

@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
Copy link
Member

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
Copy link
Author

Doomsdayrs commented Apr 13, 2024

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
Copy link
Member

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.

@jonbarrow jonbarrow changed the title ActivityPub integration [Enhancement] ActivityPub integration Sep 20, 2024
@jonbarrow jonbarrow added enhancement An update to an existing part of the codebase approved The topic is approved by a developer labels Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved The topic is approved by a developer enhancement An update to an existing part of the codebase
Projects
Status: Todo
Development

No branches or pull requests

2 participants