More work on 'previously'

[lisad]

• [ ] Figure out how to properly register it
• [ ] @bumblefudge suggests: is "previously" a neologism, btw, or is the "previously" semantic defined in some FEP or extension already? maybe a tracking issue should be made for all new Activity types and properties in each merge, so that a @Context file can be written up in final t-crossing and i-dotting stage of the report
• [x] Add the actor URL because it will be needed to verify the legitimacy of objct IDs in 'previously' against the source

[lisad]

          As the destination server copies Activity and Like objects, it SHOULD add breadcrumbs.  It SHOULD preserve the existing breadcrumbs because it’s nice to do so.  Breadcrumbs should be pushed on the top (or beginning) of a most-recently-first list in the ‘previously’ property.  The 'previously' attribute is defined in this specification as a multi-valued property, as follows: 

"actor": "https://thirdhome.example/meadowvine"
"previously": [
  { 
    "actor": "https://newsite.example.org/aurora/",
    "id": "https://newsite.example.org/aurora/items/02751cab-..."
  },
  { 
    "actor": "https://lemongrove.example.co.uk",
    "id": "https://lemongrove.example.co.uk/2016/05/minimal-activitypub"
  }
]

The "actor" value SHOULD be included, because there is no guarantee that a 3rd party can derive the actor value from an "id" value. The "actor" value is needed in order to validate the previous "id" value before trusting it. Because the destination server simply states the "previously" value, it cannot be entirely trusted. A 3rd party MAY check the original actor to make sure that it does redirect to the new Actor, but that check is not guaranteed to work because the source server hosting the original Actor may be inactive or have removed that Actor.

Open Issue:More discussion is needed for this proposal because it's not clear it can be trusted enough for 3rd parties to do anything sensible with the "previously" value. There are some use cases it would be nice to handle with breadcrumbs:

  <ul>
    <li>Cherry liked Aurora's article in its original location.  When Aurora's article moves, and Cherry sees it in a new 
      location, it would be nice for Cherry to see that it was already "liked" and not be tempted to "like" it again.</li>
    <li>Malicious user 'Voldemort' posts an article with a "previously" property including Aurora's article's ID, hoping
      to cause chaos.  It would be nice for Cherry to be able to tell that they did NOT actually "like" this article, 
      that their "like" to Aurora's article in its original location does not transfer to this article by Voldemort.  Maybe
      this can be accomplished by checking that Aurora's original server does in fact redirect the Aurora actor to their
      new location, but...
    </li>
    <li>It would be nice if Cherry can tell which articles are already liked or not even if Aurora's original server is 
      no longer accessible.</li>
  </ul>

Breadcrumbs published by the destination server do not solve these use cases with the last wrinkle added, and it's not clear how much value breadcrumbs provide without that. Are there use cases that are solved with unreliable breadcrumbs? Are there better solutions? Is the account transfer solution better without visible breadcrumbs?

[lisad]

New worry: can actor IDs have extra stuff? Does the agent using the previously list need to strip parameters or internal structure from URL in some cases to get at the actor ID? E.g. does anybody add filters/scopes to actor follows by using "https://lemongrove.example.co.uk/photos/nature" or "https://lemongrove.example.co.uk/?filter=photos/nature?

this need not be done by guessing - when the agent asks the Actor's server "GET https://lemongrove.example.co.uk/photos/nature" the Actor's server could return an Actor with the collections stripped back to the bare Actor ID