OStatus/PuSH producer

3f4qnL <a href="http://zdsoskkdikhs.com/">zdsoskkdikhs</a>, [url=http://xvwwppnetvyf.com/]xvwwppnetvyf[/url], [link=http://reklskrmvurh.com/]reklskrmvurh[/link], http://yubxcherrxhz.com/

Todo

Hub:

• accept subscription/unsubscription requests
  •   web endpoint
  • reject subs for non-canonical feeds
•   reject ping updates from outside as we're not an open-to-the-public hub
  •   web endpoint
• send update data to subscribers
  •   as queue handler
  • need to be able to individually attempt resend to each subscriber that's offline
•   provide internal API to check whether a given feed is subscribed
•   provide internal API to push updates to a feed

Producer:

•   feeds for users
• feeds for groups
• build profile info into feed streams
  • real name
  •   location [name / lat / lon] (georss already in there)
  • homepage
  • bio
  • avatar (pulling <logo> on feed for now -- we need per-user)
    • make sure we drop the 96x96 explicit requirement :)
  • tags
• build notice info in feeds:
  •   text atom:summary
  •   html atom:content
  • attachments as link/rel=enclosure (can delay consumption on that for now)
  • topics stored as atom:category, SHOULD be tags (rel-tag)
  • response stored as thread:in-reply-to
  • attention stored as omb:attn
  • repeat/retweet stored as omb:forward
•   feed update+ping on new notices
• feed update+ping on profile change (maybe just let it wait until the next post)
  • activitystreams?
• feed update+ping on other events -- activitystreams?
  • delete notice(?)
  • local user block (?)
  • delete user
• note we probably still need to be able to provide a regular-readable feed.
  • might need to store an 'outbox' stream including non-notice events
• (backgroundable) profile updates

Maybes

Less vital.

Hub:

• send renewal notices to subscribers
  • queue handler? poll?
  • actually expire dead subscribers
    • -> do we need to report this back inside so we can drop the subscriber from SN level or mark the subscriber as broken?

Producer:

• profile info
  • language (currently we don't store it for profiles though, just for user preferences)
• add site meta-info to streams?
  • character limit

Flow

• Subscriber requests a feed subscription to the hub
  • POST /push/hub -> actions/hub.php
    • confirm this is a user feed we're handling
    • save a HubSub item w/ subscription info
    • enqueue item+'subscribe' to hubverify queue for confirmation callback
• Hub sends a verification request to subscriber's callback
  • hubverify queue -> HubVerifyQueueHandler
    • POST a 'subscribe' verification to subscriber's callback URI (stored in HubSub item)
    • on success, save lease start & end time into HubSub item
    • on failure.... retry? cancel and delete the sub?
• ... time passes ...
• Subscriber user's post is processed for inbox distribution
  • enqueue to hubdistrib queue
• Prep output for remote PuSH subscribers
  • hubdistrib queue -> HubDistribQueueHandler
    • find all verified subscriptions for this user's feed
    • for each subscriber, enqueue sub & a single-item version of the Atom feed to hubout queue
• Send output
  • hubout queue -> HubOutQueueHandler
    • POST the feed to subscriber callback
    • on success, we're done!
    • on failure.... retry? mark another failure on the subscriber?
• ... time passes ...
• Hub sends a subscription renewal check to subscriber's callback MAYBE?
  • (no good way to schedule this right now? maybe while sending if we find we've passed the lease end?)
    • POST a 'subscribe' verify ping to callback
      • on success, update the lease expiration in HubSub record
      • on fail...? Retry a few times? Kill sub immediately?
• ... time passes ...
• Subscriber requests an unsubscribe
  • POST /push/hub -> actions/hub.php
    • confirm this is a user feed we're handling
    • enqueue item+'unsubscribe' to hubverify queue for confirmation callback
• Hub sends a verification request to subscriber's callback
  • hubverify queue -> HubVerifyQueueHandler
    • POST 'unsubscribe' verification to subscriber's callback URI (stored in HubSub item)
    • on success, delete the subscription record
    • on failure.... retry? cancel the unsub request?