voxpelliIt's also a challenge to know if a receiver supports doing such an upgrade and also a challenge in eg. the case of webmention endpoints such as mine and webmention.io that those endpoints are perhaps not the most well suited target for such messages
voxpelliEg. Twitter treats mentions and DM:s as two different sections of their site – a Webmention takes on the role of the mentions section, but the DM-section – that could be just as well suited for, or even more suited for, an indie-reader to handle or a standalone app
voxpelliSo while Public Page Upgrading is a really cool feature that serves many purposes, eg. allowing private accounts to be followed in an indie-reader, allows private block lists to be shared with third party tools etc I still think a dedicated DM endpoint could be a better choice for DM:s
voxpelliCreating a good Webmention endpoint is already fairly hard work with Salmention and everything – having that endpoint also having to take on all of the private messaging needs could dampen the momentum and diversity amongst webmention tools
voxpelli(Webmention endpoints typically today handle no private content, making them suddenly understand that some content can only be shown to some authenticated users would require rewriting lots of code paths and generally be prone to errors – keeping it in a separate app totally focused on just private would be less error prone)
aaronpk1) i'm not calling this private messaging, and agree that that is different enough from a UI perspective that it might be better as a different spec
aaronpk2) I don't think "Public Page Upgrading" is a useful term, not sure where that came from. This is specifically about webmention for private posts.
aaronpk3) we *do* need some way to handle webmentions for private or otherwise access controlled posts, especially since that's often the first question I get when I tell people about webmention
voxpelli2) Whether the term in itself adequately describes the concept or not I don't really know, but the fetching of a private content on a URL through the use of a token is certainly useful in additional contexts outside of Webmention
aaronpk2) I was assuming you might have other reasons for having authentication on posts, and prior to this the idea of having a webmention endpoint "authenticate" as someone seemed challenging. this explains how to do it and doesn't seem too bad.
aaronpk5) good question, I'm not sure yet. however, if you send this private webmention to someone who doesn't support it, the worst that happens is they fetch the source URL with no authentication and they are unable to verify the webmention. at least no data is leaked, and the sender also has a way to tell that the sender didn't support it if they notice that the URL was fetched without authentication.
voxpelli2) to me the new described flow consists of two independent parts: 1. an extension of the ping that can be exchanged for an access token 2. a mechanism to use a token to access additional content
voxpelliand as discussed at other times: Tokens can be obtained through many different ways – so could be good to mention that the accessing of a private URL is independent from the new ping flow and can be used with multiple other flows as well
aaronpkI could add something about the sender and receiver may have an alternative mechanism of exchanging tokens, but I do want to require Bearer Tokens (which really just means "Authorization: Bearer xxx" where xxx is a string
voxpellithat way it could also make sense to rename the flow as "Authenticated Webmention Flow" or similar – as one aspect described in the "Public Page Upgrading" part is that a post doesn't have to be private to be upgradeable – it can eg. be that additional content like perhaps sensitive person tags or such could be shown
voxpellidid you discuss the scope and lifetime of the bearer token? can a client expect it to live forever or should it typically only be valid for a single fetch?
aaronpkand that's what "realm" is for. If the webmention endpoint receives another webmention containing a previously seen "realm" for which it has a valid access token, the endpoint SHOULD skip the code exchange and use the existing token immediately to fetch the source URL and avoid generating a new access token.
voxpelliback to the "public page upgrading" case – if one wants to have a post both publicly be shown and be notified to a site owner in it's upgraded shape – then I wonder how one would solve that?
voxpelliI guess the sender should send two pings then – one with a code and one without one and the token would only be sent for the fetch caused by the ping including the code
voxpellione should probably document whether one is expected to fetch both through the code-ping or whether one should expect two pings to fetch both (+ also whether tokens should be used for none-code pings)
voxpelliand since all privately fetched content won't be shown publicly then if a code is always to be used and a token with a very wide realm has been received, then that will basically exclude all content of that blog from being publicly shown by that receiver again
voxpelliunless either the client is forced to do both code-less and code-pings and tokens are not used for code-less pings or endpoint is forced to always fetch both public and private versions of a url no matter the ping type
LoqiThe Private Webmention protocol is an extension to Webmention that supports sending and verifying Webmentions for posts that require access control https://indieweb.org/private-webmention
bearwas the private webmention discussion recorded? i''m curious about the state diagram - some of the steps seem ordered oddly and some pieces seem missing
ZegnatI think sknebel was there, which probably means the notes will be rewritten and made into a nice session page by him during the upcoming week. Those are the live notes.
sknebelbear: yeah, I'll rewrite the session notes, but most of the technical stuff is in aarons spec start and technical "holes" in there probably should be issues on its page: http://indieweb.org/private-webmention
aaronpkbear: would love your feedback on the private webmention spec! I turned our notes from the discussion into the spec which it looks like you read already
martin.atkins.me.uk edited /OpenID (+1153) "More details on Typepad's dropping OpenID consumer support" (view diff)
tantek.com created /2016/Brighton/Hack_Day_Intro (+553) "stub with sections, my entry" (view diff)
sebastiangreger.net edited /LinkedIn (+197) "/* POSSE to LinkedIn */ update on IWC/Brighton proof-of-concept" (view diff)
aaronparecki.com uploaded /Special:Log/upload "uploaded "[[File:private-webmention-flow-diagram.svg]]""
aaronpk sknebel: is this clear? https://indieweb.org/Private-Webmention#Summary
voxpelli sounds like a case of http://indieweb.org/private_posts#Public_Page_Upgrading
kodfabrik.se edited /private-messaging-brainstorming (+155) "Adding link to the original inspiration of this flow" (view diff)
KevinMarks_ Aaronpk: previously http://epeus.blogspot.com/2008/05/mixing-degrees-of-publicness-in-http.html
loqi.me edited /sparkline (+62) "Zegnat added "http://kryogenix.org/days/2012/12/30/simple-svg-sparklines/" to "See Also"" (view diff)
Loqi The Private Webmention protocol is an extension to Webmention that supports sending and verifying Webmentions for posts that require access control https://indieweb.org/private-webmention
ncollig.net created /User:Ncollig.net (+1085) "Created page with "<div class="h-card">[https://ncollig.net/ <img src="https://ncollig.net/file/29fb5b71090d7a6f18e3941bd9d73b3d/thumb.jpg" style="width:128px;float:right;margin-left:1em"/>'''<span..."" (view diff)
Zegnat bear: there are notes from the session: https://indieweb.org/2016/Brighton/directmessage