- From: Evan Prodromou <evan@prodromou.name>
- Date: Fri, 3 May 2024 20:49:50 -0400
- To: Lisa Dusseault <lisa@dtinit.org>, public-swicg@w3c.org
- Message-ID: <d1a84a99-b117-425f-a8d7-e1ba8d30e645@prodromou.name>
Lisa, How would you feel about a `Copy` activity? I think that matches what you're proposing better than `Import`. Let's say you wanted to make a copy of this object, a private note to the old user's followers: { "@context": [ "https://www.w3.org/ns/activitystreams", "https://namespace.example/ns/copy" ], "id":"https://source.example/user/olduser/note/1", "attributedTo":"https://source.example/user/olduser", "to":"https://source.example/user/olduser/followers", "type": "Note", "content": "Hello World" } The activity to make a copy might look like this: { "@context": [ "https://www.w3.org/ns/activitystreams", "https://namespace.example/ns/copy" ], "id":"https://destination.example/user/newuser/copy/1", "actor":"https://destination.example/user/newuser", "to": ["https://source.example/user/olduser", "https://source.example/user/olduser/followers", "https://source.example/user/newuser/followers"] "type": ["Copy", "Create"], "origin":"https://source.example/user/olduser/note/1", "object":"https://destination.example/user/newuser/note/5" } This format lets us identify the new note as a copy. I've used `origin` to say where the object came from, and `object` for the destination. Using these properties, I can dual-type the activity so it works as both a `Copy` and a `Create` for fallback. A client that only recognizes the `Create` activity type will do the right thing with this activity. Note that the addressees are different; the new Copy activity is addressed to the old user, to the the old user's followers, and to the new user's followers. The resulting note might look something like this: { "@context": [ "https://www.w3.org/ns/activitystreams", "https://namespace.example/ns/copy" ], "id":"https://destination.example/user/newuser/note/5", "attributedTo":"https://destination.example/user/newuser", "to": ["https://source.example/user/olduser", "https://source.example/user/olduser/followers", "https://source.example/user/newuser/followers"], "type": "Note", "content": "Hello World", "copyOf":"https://source.example/user/olduser/note/1" } The original note might also be changed to include a list of all the copies: { "@context": [ "https://www.w3.org/ns/activitystreams", "https://namespace.example/ns/copy" ], "id":"https://source.example/user/olduser/note/1", "attributedTo":"https://source.example/user/olduser", "to":"https://source.example/user/olduser/followers", "type": "Note", "content": "Hello World", "copies": [ "https://destination.example/user/newuser/note/5" ] } Evan On 2024-05-03 4:01 p.m., Lisa Dusseault wrote: > Here are my followups from today's call. Note the first one allows > folks to have a peek at LOLA as it stands even before the PR is > merged, but you might also wait for the next version after I work on > the issues listed below. > > 1. Create a PR for EvanP: Done > * https://github.com/swicg/activitypub-data-portability/pull/16 > > 2. Add a section that explains how to copy from the outbox to handle > “unaugmented” source servers > https://github.com/swicg/activitypub-data-portability/issues/17 > > 3. Do more work on use cases to motivate the choices especially make > sure the support for defederation is explained and what that means for > content copy models > https://github.com/swicg/activitypub-data-portability/issues/19 > > 4. Suggestion to have a new "Import" activity: *I'd love more > feedback*. Is anybody in a position to be able to create a wrapper of > type "Import" around content of type "Note" and test that out in the > context of an outbox? > * if this works, it can be used for importing content through other > mechanisms besides LOLA. > > 5. Add to the spec that there are legitimate use cases to BLOCK > accounts from export or move - e.g. in the case of CSAM reports > https://github.com/swicg/activitypub-data-portability/issues/18 > > Lisa
Received on Saturday, 4 May 2024 00:49:54 UTC