There isn't a strict need to wait for user interaction that I can think
of. Not sure why I suggested we'd have to wait for Bob to actually
request that message be fetched from Alice's server :X. But, from my
understanding of how the Webfinger auth scheme works, it's subscriber
against content provider; so, the delivery of the actual content would
have to be done via a pull mechanism, not a push mechanism.
So, instead of waiting for Bob, Bob's server may see the notice that
Alice has sent a message to Bob and pull it itself, but the same auth
step would apply.
Blaine, if you happen to see this and I'm saying something wrong, please
correct me :).
HTH,
--sean
Might be quicker to prototype as a plugin, but definitely something
we'll want to have available as widely as possible!
Sean, quick question on the message flow -- it sounds like the
messages won't actually get sent until the receiving server requests
it after user action. I'm still wrapping my head around the webfinger
oauth ;) ... is this all server-server communication, or does it
actually require some active authenticated sessions?
If it is all server-server, then there doesn't seem to be a strict
need to wait until user interaction to fetch the message source; a
server could simply fetch it immediately and store it locally, or send
it direct to the user by email or another local push mechanism.
Are there other reasons for the delay, such as allowing for canceling
a message after sending it if it hasn't been read, or showing a 'has
been read' notification to the sender?
-- brion vibber (brion @ status.net)