2016/Brighton/directmessage
Contents |
Direct Messaging and Private Webmentions
Participants
- Sven Knebel (sknebel)
- aaronpk
- sgreger
Notes
motivation: finding people
main issues:
- how do people know which channel to use to get in touch? (motivated by challenges of yesterday's early bird meet-ups)
- twitter does not allow DMs to non-reciprocal contacts unless they allow it (i.e.contacting in twitter is by default public, which may not always be desirable)
- every medium is only being used by a sub-group of people
long-standing convention: contact-page on the website
- aaronpk: list in order of preference
- manual, but efficient
pattern: private (unlinked) pages (tantek, sebastian greger) for high-priority contacts
- give out the URL in person, or on a business card
aaronpk has an automated indication of the current time zone he is in displayed (constant update from the smartphone)
sknebel has a separate email address he uses when traveling he gives to family and close contacts. checks that address more often when traveling and doesn't check main address except a couple times a day.
- contact forms could be translated to different channels
- contact forms could offer an option to specify priority ("notify me", "I'll see it in the evening"), then the backend takes care of delivering the message based on my own preferences
private webmentions
previous attempts:
- normal webmention to site with access control (has to be passable by webmention receiver)
- indieauth flow?
who generates the token?
- sender or receiver?
receiver:
- receiver generates token, passes it in request
- sender goes to receivers token endpoint, verifies that
- token would have to be scoped, otherwise sender could use token to read other posts send to receiver
sender a):
- just private urls? (long random tokens) (or as extra frame in webmention requests)
- +works static
sender b):
- seperate token exchange
- sender sends webmention to reciever,
- receiver fetches,notices that login required
- logs into senders page, gets token
- re-fetches with token
- +similar to how a user log ins
- +token could be reused for quick back-and-forth
- webmention could contain authorization code (OAuth terminology) -> c)
How to recognize authentication required and that the protocol is useable?
sender c):
- sender sends webmention to reciever, with authoization code
- receiver sees authorization code -> need exchange code to token
- fetch source page , get token endpoint (easy: in hhtp header of potentially 403 page, maybe in some way in page source)
- exchange authirization code to acces token
- fetch source page with authorization header
- verify source page
- allow token reuse, but each request has to include new authorization code if necessary
discover endpoint needs to include support for better UX
token reuse: how to discover scope (is old token usable for this request)
