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

M3 - Create Specification for Peer-to-Peer Extensions to ActivityPub #103

Open
6 tasks
maisutton opened this issue Nov 28, 2023 · 18 comments
Open
6 tasks
Assignees
Labels
ready for prod&comms This is done, ready to launch and communicate

Comments

@maisutton
Copy link
Collaborator

maisutton commented Nov 28, 2023

Enable “alias URLs” within ActivityPub data to point to their p2p equivalents from the HTTP counterparts. This will enable the ecosystem to gradually adopt more decentralized publishing flows while remaining compatible with the central “instance” model of ActivityPub publishing.

@RangerMauve
Copy link
Contributor

Depends on #102

@RangerMauve
Copy link
Contributor

  • Update staticpub repo with new P2P URLs and test loading it in the reader
  • Write new specification based on the format used for the ActivityPub spec, linking to relevant existing specs (e.g. ActivityPub, RDF aliases) and publish under docs website
  • Write brief description of how it works for docs site
  • Blog post announcing the spec
  • Reach out to folks in social-wg mailing list to make them aware of the spec

@fauno
Copy link
Collaborator

fauno commented Jan 10, 2024

are FEPs a canonical way to do this?

@RangerMauve
Copy link
Contributor

Yeah! We should structure the spec as a FEP

@sutty-coop
Copy link
Collaborator

Mauve: I changed the completion date to March 15th bc the reverse timeline said:
| -1 | Extensions spec
If that's not the estimation, let me know or let's take it back to Feb 29th (date stated as completion date here)

@RangerMauve
Copy link
Contributor

So, I think sadly the best way forward would be to publish multiple copies of the ActivityPub files since there's clear way we can represent links to p2p objects.

e.g. even if the Actor had an extra property pointing to it's p2p representation, it'd need to point to the HTTP version of it's outbox items.

I think the safest bet would be to use sameAs functionality. We'd have a separate set of AP objects per p2p/http representations.

Might be good to poke folks in this thread about the subject: https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101/16?page=2

The identity proofs spec might also be relevant for us: https://codeberg.org/fediverse/fep/src/commit/e98aae3d2c561913d0189064f85236b6adfe871f/feps/fep-c390.md

The alsoKnownAs property seems to be what Mastodon is making use of: https://socialhub.activitypub.rocks/t/defining-alsoknownas/907

Unclear if this could be used for activities and notes.

Maybe we could figure out a spec for relative URLs in IDs to save on duplication?

@RangerMauve
Copy link
Contributor

@RangerMauve
Copy link
Contributor

Post asking for feedback on the property name: https://mastodon.mauve.moe/@mauve/111926822827079732

@RangerMauve
Copy link
Contributor

This is promising: https://codeberg.org/fediverse/fep/src/branch/main/fep/fffd/fep-fffd.md

We could store in the url field with a rel: alternate and keep the mime type. Fits well with webmention.

@RangerMauve
Copy link
Contributor

Initial PR to staticpub based on fep-fffd: https://github.com/RangerMauve/staticpub.mauve.moe/pull/2/files

@fauno
Copy link
Collaborator

fauno commented Feb 14, 2024

Regarding FEP fffd I checked Mastodon's code and when it finds that the url attribute of an activity/actor is an array of objects, it'll pick the first one with mimeType equal "text/html" and ignore the rest.

So if we list the HTTPS versions first, anything that comes afterwards should be compatible, even if it's the HTML version on IPFS.

@fauno
Copy link
Collaborator

fauno commented Feb 14, 2024

Media attachments are expected to be downloadable via HTTP and if they fail it'll keep retrying three times. It's hard-coded that it'll only download four if there are more.

The current way to work around this would be to produce an unparsable URL, use a mime type like "image/png; ipfs" or let the Mastodon queue fail three times. Or send a patch!

Files involved:

app/workers/redownload_media_worker.rb
app/lib/activitypub/activity/create.rb
app/lib/activitypub/parser/media_attachment_parser.rb

@fauno
Copy link
Collaborator

fauno commented Feb 14, 2024

Looks like others would still expect the url attribute to be a string: https://github.com/superseriousbusiness/gotosocial/blob/main/internal/api/model/status.go#L58

@fauno
Copy link
Collaborator

fauno commented Feb 14, 2024

I'm not profficient enough in Elixir to check what Pleroma does

@RangerMauve
Copy link
Contributor

We expect using arrays of objects in the url field can bust some impls, but we can see about sending patches for that since reusing this FEP will strengthen us longer term

@RangerMauve
Copy link
Contributor

Gotta make sure we specify html links should go first

@fauno
Copy link
Collaborator

fauno commented Mar 7, 2024

I'm thinking of adding it to the Jekyll plugin as sub-plugin, what do you think?

@sutty-coop sutty-coop moved this from Todo to Needs triage in Distributed Press Organizing Jun 6, 2024
@sutty-coop sutty-coop added the question Further information is requested label Jun 6, 2024
@sutty-coop sutty-coop moved this from Needs triage to In Progress in Distributed Press Organizing Jul 18, 2024
@RangerMauve
Copy link
Contributor

Opened a PR, waiting for review / feedback.

https://codeberg.org/fediverse/fep/pulls/379

@sutty-coop sutty-coop added ready for prod&comms This is done, ready to launch and communicate and removed question Further information is requested labels Jul 26, 2024
@AnaFukelman AnaFukelman moved this from In Progress to Done in Distributed Press Organizing Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for prod&comms This is done, ready to launch and communicate
Projects
Status: Done
Development

No branches or pull requests

4 participants