- 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