#dev 2018-01-15

2018-01-15 UTC
snarfed joined the channel
#
gRegorLove
Aha, I see php-mf2-twitter-shim is deprecated in favor of Xray anyway. I'll give Xray a try rather than write code :)
#
GWG
I may tackle that for my version of x-ray and
[cleverdevil] joined the channel
#
[cleverdevil]
Hey, it looks like aaronpk solved the image duplicates issue in Xray, which makes my experience in Together much much better πŸ™‚
#
Loqi
aaronpk has 106 karma in this channel (1533 overall)
KartikPrabhu joined the channel
#
GWG
Mel Choyce is saying that
#
GWG
Interesting
#
[kevinmarks]
and Jeremy Felt
#
GWG
I didn't think anyone cared in that bunch. Nice to know
#
GWG
[kevinmarks]: I wonder if they'll talk to the Pings and Trackbacks Component Maintainer for WordPress
eli_oat joined the channel
#
@Kraft
@ChrisHardie @megarush1024 @melchoyce Yup, I've been trying to slowly help indieweb with spare cycles. Webmentions are really powerful and something that could power a lot of stuff like this. I can ping you Mel when I'm back at my desk what I know.
(twitter.com/_/status/952721946030039040)
#
@ChrisAldrich
@melchoyce @jeremyfelt Not coincidentally, @dshanske, the maintainer of Pingbacks/Trackbacks is a major contributor to the WordPress Webmention plugin as well as many other IndieWeb related WordPress tech. http://boffosocko.com/2018/01/14/updating-pingbacks-with-webmention/
(twitter.com/_/status/952722667630559232)
renem_ and snarfed joined the channel
eli_oat joined the channel
#
GWG
I have a problem I'm stumped on
#
GWG
The way that the WordPress Indieauth system was set up, you can set the website URL to any arbitrary site, then use Indieauth to get a token, and Micropub will match it against the address you set in your profile. I'm wondering how secure that is. If it is a potential security issue.
#
GWG
If you are a Micropub server, and you previously received a token, since the token doesn't come with a URL, how do you know which token endpoint to verify it against?
#
gregorlove.com
edited /XRay (+80) "/* IndieWeb Examples */ +me"
(view diff)
snarfed, [tantek] and [jeremycherfas] joined the channel
#
[jeremycherfas]
!tell zegnat but Snark == Boojum
#
Loqi
Ok, I'll tell them that when I see them next
[tantek], [pfefferle], KartikPrabhu, AngeloGladding, cweiske and barpthewire joined the channel
#
@samim
The #indieweb now has sent 1 Million Webmentions - All distributed and peer to peer. https://snarfed.org/1-million-webmentions 1 billion next year?
(twitter.com/_/status/952830715120488449)
#
Zegnat
GWG, yes, a Micropub endpoint can really only work with 1 token endpoint at a time
#
Loqi
Zegnat: [jeremycherfas] left you a message 2 hours, 30 minutes ago: but Snark == Boojum
John____ and jeremycherfas joined the channel
#
petermolnar
had anyone tried this: https://lunrjs.com as search engine on a static site?
#
petermolnar
I'm trying to figure out if it's possible to build an index from python, but it looks like I'd need to run node which I really wish to avoid
#
Zegnat
But is there a reason you need to use the user's token endpoint? Isn't it just for letting the user login (authentication)?
#
cweiske
petermolnar, that looks like each client has to download the whole search index with his browser to do searching
#
cweiske
For web applications with all their data already sitting in the client, it makes sense to be able to search that data on the client too. It saves adding extra, compacted services on the server. A local search index will be quicker, there is no network overhead, and will remain available and useable even without a network connection."
#
petermolnar
that is true, but without a copy of the corpus, it shouldn't be that terrible, in theory
#
petermolnar
I mean the index itself should be small...
#
cweiske
that has to be tested
#
petermolnar
although I'm very happy with the fts5 engine in sqlite
#
petermolnar
but with corpus, that is ~2MB for my site
#
petermolnar
in the age of MBs of JS, it's fine I guess :D
#
dgold
petermolnar: I've been looking at this: www.sphider-plus.eu
#
petermolnar
no, thanks; I've played around enough with python's whoosh
#
petermolnar
sqlite is perfect for this matter
#
petermolnar
also, a php solution is not a gain for static sites
#
dgold
<shrug> I've been looking at it as a discrete domain
#
cweiske
dgold, I am running my search on a separate domain
#
cweiske
search.cweiske.de
#
dgold
cweiske: oooh, nice. and php too.
#
dgold
me likey
#
cweiske
I checked nearly all of the software linked on /search, and finally decided to implement my own
[kevinmarks], barpthewire and myfreeweb joined the channel; John____ left the channel
#
@TekstMeester
Slimme linkbuilding-strategie: volg jouw online vermeldingen/webmentions https://goo.gl/vGwLbp
(twitter.com/_/status/952876314503057408)
#
GWG
Zegnat: I'm trying to follow the specification. It says you are supposed to discover the endpoints. I think clarity is needed there in the text
#
Zegnat
What part of the spec are you trying to follow? Authorization (which uses a token endpoint) is for the user to authorize an application to do things with their profile URL. If you instead need an access token for the WP site (not for the user’s URL) you should be using a token endpoint for the WP site - and that will always be the same one.
[tantek] joined the channel
#
GWG
"For the Authorization workflow, the client needs to find the user's authorization_endpoint and token_endpoint" - Why find it if you won't be using it?
#
Zegnat
That’s for Authorization though. Don’t you need Authentication?
[kevinmarks] joined the channel
#
GWG
I need both
#
Zegnat
So, you are looking to do the same thing as I am doing with Sink?
#
GWG
Which is?
#
GWG
What is Sink?
#
Loqi
Sink is an experimental site by Martijn van der Ven that allows anyone with an IndieAuth enabled URL to post to it using any Micropub client https://indieweb.org/Sink
#
@nhoizey
@tkadlec Awesome news for Webmentions, we need to get more people using it!
(twitter.com/_/status/952884623763263489)
#
Zegnat
Sink lets anyone authenticate with an external personal URL, but it is also its own authentication endpoint and token endpoint so it does authorization for all users when they want to use a Micropub client.
#
GWG
I am trying to make WordPress a full Indieauth client. Basically, implement everything
#
aaronpk
Client? Why?
#
Zegnat
But a client that tries to get some authorization from a user should also have a reason for that authorization. I don’t really follow what WordPress needs to be authorized to do.
#
aaronpk
Yes that
[pfefferle] joined the channel
#
[pfefferle]
log into the wiki, crosspostings via micropub, …
#
GWG
Maybe I am confused
#
aaronpk
Cross posting to what? Other Micropub sites?
#
cweiske
so sink is the same as commentpara.de
#
cweiske
but without the anonymity
leg joined the channel
#
GWG
Right now, I taught WordPress to accept an Indieauth token as an authentication method, so I could use that to access the WordPress REST API, which opens up a lot of things.
#
GWG
I also upgraded [pfefferle]'s original authentication code to use the method outlined in the specification
#
GWG
So, two separate things.
AngeloGladding joined the channel
#
GWG
But, I didn't implement discovery, so I was implementing that. So, now the code goes out and looks for the endpoints.
#
GWG
For the login code, it's fine.
#
Zegnat
cweiske: yes, anyone can post but you need to authenticate first. A bit like if the wiki would have a Micropub endpoint.
#
[pfefferle]
GWG but how have you done it without the discovery part?
#
GWG
But the question is, for the code that verifies tokens, the specification doesn't explain how if you get a token, you figure out where it come from?
#
aaronpk
GWG: i'm a little confused. I think maybe you're doing something that doesn't make sense
#
GWG
aaronpk: I'm willing to accept that
#
GWG
[pfefferle]: The original code hard-coded the endpoints
#
aaronpk
are either of you available for a call in an hour or so?
#
GWG
A call?
#
[pfefferle]
yes, but from indieauth.com… I thougt you implemented the full spec
#
GWG
[pfefferle]: I implemented parts of the spec.
#
GWG
Still working on all
#
aaronpk
this might be easier to work out on video chat
#
GWG
aaronpk: Won't be available till tonight
#
Zegnat
A token issued by a token endpoint on example.com only carries authorizations for example.com, GWG. So if you are letting the user’s token endpoint generate a token, that token does not apply to the WordPress site at all. The WordPress site needs to issue its own tokens for use with its own endpoints. And that’s how you will always know where the t
#
Zegnat
oken came from, namely: your own token endpoint.
#
Zegnat
hopes that made sense.
#
GWG
So, why discover the endpoints if I always have to use the ones the site recognizes?
#
GWG
That is what I'm confused about, I guess.
#
GWG
It says I MUST discover them
#
aaronpk
I think you're mixing up being a client and being a server
#
[pfefferle]
a user uses his site to authenticate
#
GWG
aaronpk: I may be.
#
[pfefferle]
so you have to check the endpoints, to authenticate
#
Zegnat
No, you must discover if you want authorization to do things with the user’s URL. But you don’t want to do things there, so you should not have to implement authorization.
#
[pfefferle]
it is not always indieauth.com
#
[pfefferle]
this is only, kind of a fallback
#
Zegnat
Basically: only discover a token-endpoint if you are also discovering a micropub-endpoint.
#
aaronpk
we really need to separate the idea of the wordpress plugin logging the user into wordpress itself vs issuing tokens to be used by external micropub clients
#
GWG
aaronpk: I am writing the code for both.
#
[pfefferle]
ah, ok, now I understand the porblem
#
GWG
Which may be why I'm confused.
#
GWG
[pfefferle]: Can you explain it to me?
#
GWG
I may be confusing myself here
#
Zegnat
If WordPress is the Micropub endpoint, then WordPress should be choosing the token endpoint. A Micropub client would be implementing *authorization* discovery to find a Micropub-endpoint and token-endpoint on the WordPress site. This client will never visit a user’s page to find their own specific token-endpoint. The user’s chosen token-endpoint is
#
Zegnat
completely irrelevant for posting to a WordPress site.
#
GWG
I have two functions I built
#
[pfefferle]
that’s why you have two endpoints
#
[pfefferle]
the token is only if you want to access an API
#
[pfefferle]
like micropub
#
[pfefferle]
There are two flows, one to authenticate and one to authorize
#
GWG
So, I'm doing discovery in the wrong place for one of the two workflows?
#
GWG
For the tokens, I should be doing discovery on the server, not on the cuser?
#
GWG
But, in the other workflow, I do discovery on the user?
#
[pfefferle]
you have to always discover the endpoints
#
[pfefferle]
look a t the code of cweiske.de
#
[pfefferle]
no, for both you have to discover the endpoints
#
[pfefferle]
he has his own authorisation endpoint
#
[pfefferle]
so he can login to the wiki or to wordpress without using indieauth.com
#
Zegnat
GWG you should only go and discover a token endpoint on the user’s URL if you are also discovering an API endpoint (e.g. Micropub) at that same URL.
#
aaronpk
this timing is funny because i'm on an IETF call about a new "Distributed OAuth" spec right now
#
aaronpk
for logging in to wordpress, you don't need to discover anything because there isn't anything to discover. the plugin is really just using indieauth.com (soon indielogin.com) to handle RelMeAuth
#
aaronpk
letting the user configure which login service to use would be a plugin setting
#
aaronpk
also there is no token endpoint involved in that flow at all
#
Zegnat
I found this very confusing at first too. I thought it obvious that a token endpoint goes hand in hand with an authorisation endpoint. In reality it goes hand in hand with API endpoints like Micropub. (At least that new way of thinking made it more clear to me.)
#
[pfefferle]
yes, but GWG and I wanted to rewrite it, to also support indieauth
#
aaronpk
what i'm saying is I don't think it makes sense to support IndieAuth authentication for logging in to wordpress
#
Zegnat
That’s still just logging in, that is authentication, and the authentication flow does not use token endpoints, [pfefferle] :)
#
aaronpk
what's your expectation of the end-user flow of how people will actually end up using IndieAuth for logging in to wordpress?
#
sknebel
aaronpk: I think it would make sense for multi-user scenarios?
#
GWG
aaronpk: I reimplemented logging into WordPress with it because that was already in the plugin. I really am focusing on the other piece.
#
GWG
aaronpk: People were doing it.
#
aaronpk
sknebel: okay yeah multiuser blogs makes sense
#
aaronpk
GWG: I think what people were doing was RelMeAuth to log in to their wordpress
#
Zegnat
Oh, sorry, you mean a different multi-user scenario. *face-palm(
#
GWG
aaronpk: Good point, but it has over 200 installs
#
aaronpk
if you want to let people log in to their site with IndieAuth then you still don't ever touch a token endpoint
#
Zegnat
The WP case gets interesting when you have people with multiple WP blogs. If their main blog implements an IndieAuth authorisation endpoint they can use that to log in to the other blogs that work with IndieAuth authentication.
#
Zegnat
But I would almost say those are 2 separate plugins.
#
aaronpk
they are functionally completely different things, but I can see why 2 plugins would be confusing, since they'd both be called IndieAuth
#
aaronpk
you could call them "IndieAuth Login" and "IndieAuth Server" but i'm not sure that's actually a good idea still
#
Zegnat
No, that would be extremely confusing.
#
cweiske
the wp case is always interesting if you have a central auth server and don't want passwords for each website
#
aaronpk
in any case if someone wants the WP indieauth server part, you would want a setting to let them disable the indieauth login for logging in to wordpress
#
Zegnat
And you could be stacking the two plugins, theoretically. WP needs to be a Server to support Micropub, but within there you could still use Login through IndieAuth, to get the Sink case.
#
Zegnat
Not necessarily aaronpk ;)
#
aaronpk
I can definitely see a scenario where someone doesn't want to add the URL login box to wordrpess but still wants the built-in indieauth server
#
Zegnat
The IndieAuth Server WP should hand-off to whatever is set as the sites preferred login screen. That login screen may or may not also be IndieAuth.
#
Zegnat
thinks this should be going into an Etherpad or something
#
aaronpk
yes i'm just saying that the plugin shouldn't always enable the web sign-in box on wordpress
#
aaronpk
needs to be something the user can turn off
#
Zegnat
also thinks this must have made GWG’s head spin
#
aaronpk
GWG [pfefferle]: another thing: if you're enabling full IndieAuth logins, that also doesn't necessarily mean you should hard-code indieauth.com for RelMeAuth as well.
#
Zegnat
I think indielogin.com was a hard-coded fallback?
#
aaronpk
anyway the main point is: for logging in to wordpress, the plugin should be a normal IndieAuth client, which discovers the user's authorization endpoint and checks the code there, no access tokens involved. when you go to add the indieauth server part to the plugin, then the plugin will be issuing its own tokens.
#
GWG
aaronpk: Maybe I should just bump up in priority writing my own server
#
GWG
Trying to use any arbitrary one is what is adding to the issue
#
aaronpk
i'd say sort out the new login flow first, since it's going to be completely separate code from the server
#
GWG
So, implement web sign in....hmm...
#
GWG
Right now, the way pfefferle set it up, its an extra box on the login form. But it probably should be a separate form
#
cweiske
GWG, you can use commentpara.de for testing login with a separate indieauth server
#
aaronpk
I haven't seen people get confused by that, it's fine
#
GWG
My next step after discovery was going to be improving the matching of URLs to WordPress users
#
GWG
It is still a bit raw
#
aaronpk
GWG: you can also drop https://github.com/dissolve/selfauth into a folder on one of your test domains to turn it into its own auth server
#
Loqi
[dissolve] selfauth: self-hosted auth_endpoint using simple login mechanism
AngeloGladding joined the channel
#
GWG
aaronpk: I'm going to keep working on this, now that I've figured out what confused me.
#
GWG
My intention is to get to a public release before diving back into running a server
#
cweiske
commentpara.de is already running
#
GWG
By the way, I already added a setting to turn off the login and keep the token authentication. I don't really want the login functionality, but some people do
#
aaronpk
that is the part i'm not sure is correct
#
GWG
aaronpk: Which part?
#
aaronpk
did you make the wordpress plugin issue its own tokens for that use?
#
GWG
aaronpk: I'll be seeing you on the weekend. Can I bend your ear on it?
#
GWG
aaronpk: No. It's using Indieauth right now.
#
GWG
But eventually...
#
aaronpk
so..you're using the auth code?
#
GWG
Indieauth.com, excuse me
#
GWG
For which use?
#
aaronpk
the API use you're talking about
#
GWG
No. It is using tokens from the indieauth.com endpoint, or any endpoint set in the WordPress backend.
#
aaronpk
indieauth.com doesn't issue access tokens
#
GWG
So, the trust is there that the WordPress site trusts that token endpoint.
#
aaronpk
do you mean tokens.indieauth.com?
#
GWG
aaronpk: Yes, tokens.indieauth.com
#
GWG
I think the problem is I'm getting my terms all mixed up
#
GWG
That's why the idea of trusting any arbitrary token endpoint was confusing me. But that was how I was reading the specification.
#
aaronpk
I think you'll have to walk me through this flow, I don't quite understand the situation yet
#
GWG
aaronpk: I may open an issue to clarify that
#
GWG
aaronpk: Okay. I used Gimme a Token to get a token from tokens.indieauth.com for my URL.
#
GWG
Then, used that token as a method of identifying myself to the WordPress REST API
#
GWG
The token provides a me property, which is mapped to a WordPress user
#
aaronpk
ah I see what you did
#
aaronpk
i'm going to have to double check, but i'm pretty sure there are some bad security implications of trying to do what you're doing there
#
GWG
aaronpk: To which?
#
aaronpk
trying to have the plugin accept a token that wasn't issued by it
#
GWG
I'm worried about security, which is why I'm trying to work on this.
#
aaronpk
or more precisely, trying to accept arbitrary tokens that it didn't issue
#
GWG
aaronpk: Only ones from its set token endpoint.
#
GWG
Wouldn't the fact the site trusts the token endpoint address that?
#
GWG
You wouldn't let the site verify against any arbitrary endpoint
#
GWG
Which is what was confusing me earlier
#
aaronpk
yeah if there's a plugin setting that points to only one token endpoint then yeah you can use it to verify the token
#
GWG
aaronpk: That is what I'm doing
#
GWG
I'd like to someday replace that with a local token endpoint
#
GWG
But not there yet
#
GWG
I let the site set the endpoint and stick to it
#
GWG
Previously, the endpoints were hard coded instead of being changeable options
#
aaronpk
so this is still only going to work for single-user sites
#
GWG
How so?
#
GWG
The specification allows for the user profile URL to be example.com/username
#
GWG
WordPress has that
#
aaronpk
well since I have my own token endpoint, if I were to log in to one of your multi-user sites, there's nothing in what you described that would let this plugin check tokens against my endpoint
#
GWG
aaronpk: Now I'm confused again
#
aaronpk
ok not single-user but single-domain
#
GWG
Either each site user gets to check against their own endpoint, or only against the one set by the site as a whole. Which is recommended?
#
GWG
I want to limit it to the token endpoint for the domain, or the WordPress installation
#
aaronpk
none of this is recommended :) the plugin should be issuing its own tokens
#
GWG
aaronpk: I'll get there
#
GWG
I have a book on the subject
#
aaronpk
have you tried logging in to Quill with this yet?
#
aaronpk
I don't think what you've described would actually work with that, unless there is more that I haven't heard
#
aaronpk
(for the actual multi-user part I mean)
#
aaronpk
maybe we need to document all the different use cases so we can talk about them easier
#
aaronpk
I can start a brainstorming section on https://indieweb.org/Wordpress_IndieAuth_Plugin
#
GWG
aaronpk: Please do
#
GWG
I'll add to it after work
#
GWG
aaronpk: I haven't tried with Quill because Micropub has its own token verification code. But I intend to submit a PR to snarfed that would allow my code to optionally preempt his if installed so I can do that
#
GWG
aaronpk: I'll buy you a beverage on the weekend
#
[pfefferle]
as aaronpk said, I think we should implement token authorisation independent from authentication
#
[pfefferle]
and the authentication should be optional
#
[pfefferle]
so that the page admin has to optin
#
GWG
The page admin or the site admin?
#
GWG
So, on a per-site basis?
#
GWG
So, I need another setting
#
GWG
I have one to turn off the authentication. I need one to turn off the authorization
#
aaronparecki.com
edited /authorization-endpoint (+25) "/* Redirect URI verification */"
(view diff)
#
aaronparecki.com
edited /h-x-app (+37) "/* See Also */"
(view diff)
#
[pfefferle]
I think authentication is enough
#
[pfefferle]
I think we can disable authorisation by default and only activate it with the first app that needs authorisation
#
GWG
[pfefferle]: Will do in next PR
#
[pfefferle]
GWG for rel-me-auth, we can match these URLs with the author-permalink
#
GWG
[pfefferle]: Which means Indieauth has to match them to pass them for rel-me-auth in the case of indieauth.com at the least, and a few others
#
[pfefferle]
kind of: if same domain, use rel-me-auth, except the user page has an authorisation endpoint on a different domain πŸ˜„
#
GWG
[pfefferle]: So did I, in the Indieauth plugin. You already merged that PR.
#
GWG
Although your REGEXP is probably nicer than my version
#
[pfefferle]
oops πŸ˜‰
snarfed joined the channel
#
GWG
I just hate when I take what I thought was simple and it ends up being vastly more complicated
#
[pfefferle]
that’s why I stuck with indieauth.com πŸ˜‰
#
aaronparecki.com
edited /Planning (+179) "/* Summit */ possible dates"
(view diff)
iasai joined the channel
#
aaronparecki.com
edited /Planning (-332) "/* Summit */ moved to [[2018/Planning]]"
(view diff)
#
aaronparecki.com
edited /Planning (+86) "/* Planned */ add NΓΌrnberg, spell out dates because 20..21 syntax is obtuse"
(view diff)
[kevinmarks], snarfed, iasai_, gRegorLove and eli_oat joined the channel
raretrack, iasai, iasai__, cweiske and leg joined the channel
#
gRegorLove
aaronpk++ xray is working great for my reply-contexts, no more truncated tweets :)
#
Loqi
aaronpk has 107 karma in this channel (1534 overall)
#
aaronpk
I saw your note about the private tweet thing
#
gRegorLove
I ended up getting the original tweet and just adding a 'protected' key at the same level as 'data'; working for me so far.
iasai__ and [kevinmarks] joined the channel
#
[kevinmarks]
ah google+ uses microdata, not json-ld
#
[kevinmarks]
yay metacrap
snarfed and [miklb] joined the channel