Olá Craig Andrews e a todos.
On Sunday 19 September 2010 01:30:56 Craig Andrews wrote:
> I'm wondering how favoring a notice that is not currently on your home
> StatusNet instance could work. Here's an example:
>
> My account is on http://identi.ca/candrews. Let's say I'm browsing around
> teh intarwebs, and come across a notice at http://obscure.com/notice/123
> which I like. I am not subscribed to this obscure user's stream, nor do I
> want to - it's just a one off notice I like. Because the site is obscure,
> no one at identi.ca has subscribed to this user's stream, so
> http://obscure.com/notice/123 isn't known as a remote notice in
> identi.ca's database.
>
> I would like to favorite http://obscure.com/notice/123 Ignore the fact
> that there is no UI to do so for now :-)
>
> 1. At the protocol level, can OStatus favor this notice? Or would
> subscription/previous awareness be required?
>
> 2. If it is possible at the protocol level, at the StatusNet code level,
> how can we send that favor notification? (Again, ignoring the fact there
> is no UI to do so for now)
The place I'd tend to start is at the StatusNet API level; since right
now your client (or the web UI) can poke a local notice ID in we're
limited to working with notices that are already in the system.
I think a sensible extension would be to allow stuffing a notice URI
into that parameter in the API; if the referenced notice is already in
the system we can pull it right up, otherwise we can go fetch it and
import it transparently.
There are a few issues though...
First, we don't have a good way to go from 'remote notice URI' to
fetching it in machine-readable format from the remote site. If it's a
URL we can go to the page, but there's no guarantee of standard
formatting there...
If it's a StatusNet site we could do API discovery from there and
perhaps do a request for the individual notice by URI, so that's
probably not unsolveable... but I don't know how easily we could
standardize that.
Second, just a note that the newly imported notice would get an ID
number on the top of the current stack, so could end up with ordering
issues if we have some things ordering by timestamp and some things
ordering by ID. (That's a general problem already though when bridging
is delayed or funky imports get done.)
At the higher OStatus-y level... the way we handle subscriptions right
now is to sorta say 'ask the user who they are, then redirect over to
that web site and let it deal with the subscription setup'. We should be
able to do pretty much the same thing for initiating favoriting from a
foreign site:
* prompt for the user's home account (if not already known/remembered)
* do webfinger & xrd discovery to find ostatus UI points
* redirect to the home site's "favorite a remote notice" endpoint, with
the URI of the notice
* home site fetches the remote notice if necessary, gets user's
confirmation of the favoriting action
^- above is not yet implemented, but very similar to subscribe workflow
v- below is already in the system
* local favorite is added on the imported notice
* OStatus/Salmon ping to the remote site to notify it of the favoriting
On 9/19/10 3:00 PM, (``-_-´´) -- BUGabundo wrote:
That reminds me sooooooo much of my old wish bug for a StatusNet "proxy"
like, that would allow you to browser a remote server with your
credencial/account
*nod* I've been thinking about good ways to present that; there's
definite advantages to being able to see user profile, group info etc as
well as notice streams through the interface of your home site -- you'll
have all your native controls for sub/unsub/block/join/leave etc on
profiles and fave/repeat/reply/etc on notices.
I'm not sure how easily we can squeeze that into the current arch on
StatusNet but it's definitely on my mind for potential 2.0 architectures.
-- brion
_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev
