OStatus and domain changes

What can affect OStatus subscriptions when a domain is changed?

Stuff to fix

 * webfinger: accept old domains (alice@newamsterdam.old -> interpret as alice@newyork.new)
 * by happy coincidence, UserxrdAction doesn't validate the domain yet. :) Should be fine.
 * added a comment to make sure we don't break that if we add validation in future [0.9.x 80e0e60]
 * Salmon POSTs: accept POST on old domain without redirecting
 * this redirection is handled in low-level Status_network code
 * PuSH POSTs: accept POST on old domain without redirecting
 * this redirection is handled in low-level Status_network code
 * Ostatus_profile::localGroupFromUrl currently hardcodes the present domain/URL scheme
 * needs updating to check uri field
 * [0.9.x 617b6f4] should do it
 * We have a user_group.uri but this isn't filled out for all local groups yet?
 * need to set user_group.uri for all groups on identi.ca
 * [master c6e8fbe] scripts/fixup_group_uri.php to fill in empty user_group.uri entries; needed before changing domain names on sites that are hosting groups for remote users
 * PuSH subscription management: may need to funk around, not sure exactly yet?

If we add 'alternate domains list' for OStatus special cases, we could have it handle multiple variants of the PuSH feed URLs for outgoing pushes and for subscription management, as well as the webfinger lookups.

Redirection issue notes -- Status_network::setupSite checks the reported $servername against $sn->hostname if present, or else $sn->nickname with the $wildcard appended. After changing the domain, this means that direct hits where $servername doesn't match what we expected *will* trigger the redirection, regardless of whether the 'hostname' field is filled out. In order to prevent this redirect from happening, we'd need to pass the new, 'correct' host in as the $servername parameter to Status_network::setupSite.

Where do we store URIs and URLs
Identifier URIs
 * ostatus_profile.uri (identifier and discovery)
 * used to uniquely identify a particular profile when receiving incoming messages, and hook them up with subscribers, existing notice streams, etc
 * used for discovery of feed, salmon endpoint etc (via HTTP or Webfinger)
 * via HTTP, should redirect ok
 * via Webfinger.....???

Addressable URLs
 * profile.profileurl (as a link)
 * ostatus_profile.feeduri (URL for source feed)
 * used as key to feedsub.uri; to start/stop PuSH subscription
 * ostatus_profile.salmonuri (URL for salmon post endpoint)
 * used to send notifications for sub/unsub/join/leave/fave/reply/etc
 * feedsub.uri (URL of source feed)
 * used for PuSH hub discovery, is passed to PuSH hub when starting/stopping subscriptions
 * feedsub.huburi (URL of feed's PuSH hub)
 * used to ping the remote hub for starting/stopping subscriptions
 * hubsub.topic (URL of the feed that a subscriber is listening to)
 * hubsub.callback (URL of the remote site's callback which will receive messages from this feed)

Changing a poster's URL
notes are in theory -- need to test

Scenario:
 * bob@boston.other is subscribed to alice@newamsterdam.old
 * newamsterdam.old moves to newyork.new
 * profile URIs should not change; http://newamsterdam.old/user/id/1234 is retained (redirects -> http://newyork.new/user/id/1234)

Regular message post:
 * alice@newyork.new posts a notice
 * newyork.new's built-in hub looks for subscribers for http://newyork.new/api/statuses/usertimeline/1234.atom
 * there aren't any subscribers to this URL in hubsub table, so nothing is sent out

If hubsub.topic entries are updated to the new URLs, then...
 * newyork.new's hub sends a message to http://boston.other/main/push/callback/5678
 * the feedsub ID on the PuSH receive URL identifies the message as belonging to ostatus_profile with uri=http://newamsterdam.old/user/id/1234, which is handed the feed for processing
 * contents of the feed should identify the sender as uri=http://newamsterdam.old/user/id/1234, which matches
 * ostatus_profile should update the profile page link etc to match
 * but it probably won't change the feed/salmon info

bob@boston.other unsubscribes from alice@newyork.new
 * PuSH unsubscribe request is sent to http://newamsterdam.old/main/push/hub for the topic http://newamsterdam.old/user/id/1234
 * if the POST gets a 301, it'll get confused

If things are special-cased to handle the POST directly without redirect:
 * hub accepts the unsubscribe request

If things are special-cased to handle the POST directly without redirect, and the feed URI is updated in hubsub:
 * hub doesn't recognize the topic; it responds as if the unsub was ok but doesn't actually remove the subscription
 * posts from alice will still get sent to to bob's server, where they get ignored

Changing a subscriber's URL
notes are in theory -- need to test

Scenario:
 * alice@newamsterdam.old is subscribed to bob@boston.other
 * newamsterdam.old moves to newyork.new
 * existing profile URIs should not change: http://newamsterdam.old/user/id/1234 is retained

Regular post:
 * bob@boston.other sends a notice
 * boston.other's hub finds a PuSH subscription for bob's feed with callback http://newamsterdam.old/main/push/callback/7890
 * POST to that URL receives a 301 redirect and isn't processed

If we special-case things so the POST is handled directly instead of redirected:
 * alice will receive the notice just fine

Reply:
 * could be some issues with addressing Salmon pings

Groups
Group memberships are by profile; profiles are identified by their URIs. If the URI of a group member changes, the group will no longer recognize them as a member and will reject their posts.

Posting to remote groups is done via Salmon ping; addressing is by URI. If the group's URI changes, remote members' posts will not be accepted by the group as they won't be recognized as being addressed to the group.

As long as URIs stay as-is and PuSH/Salmon hits are forwarded/processed correctly, I think this will be ok.