#dev 2021-07-07

2021-07-07 UTC
alex11 and [fluffy] joined the channel
#
[fluffy]
With all of the recent push towards IndieAuth Ticket Auth, has anyone built a simple standalone PHP-or-whatever ticket endpoint for testing purposes that one could deploy locally?
#
[fluffy]
Also, are we just not providing scopes for ticketauth-provisioned tokens?
#
GWG
[fluffy]: I was going to ask that. The scopes question
#
[fluffy]
looks like there’s also an open debate about the whole ‘resource’ thing, like whether a token should be valid for the whole site or just for the page it was requested against. IMO it should be up to the ticket granter to make that decision, since like… in my case when someone’s logging into my site, I’m giving them a ticket for the whole site.
#
GWG
Well, if we base it on resource indicators, it should be valid for everything under the URL.
#
GWG
I'd say we should to be consistent.
#
[fluffy]
Yeah, I’m fine with that interpretation too
#
GWG
But I'd like scope and resource
#
[fluffy]
I’ll just always make my resource the root URL 😛
#
GWG
Resource indicates the path and scope indicates the permissions on that path
#
[fluffy]
it already has resource, doesn’t it?
#
GWG
Just saying why I think both should be present.
#
GWG
Resource without scope implies unlimited access to a resource
#
GWG
We have the scope in Microsub for read, but that is read access to channels, not to posts.
#
GWG
On the other hand, I suppose a lack of scope could imply only read access to a resource
#
GWG
But that's a discussion also
#
[fluffy]
yeah I plan on making my thing flexible, and also in my implementation the ticket itself is going to be a short-lived token with a scope of ‘ticket’ in addition to whatever other scope(s) are on the request
#
[fluffy]
and then the final token grant will have the ‘ticket’ scope removed
#
GWG
I'm just excited that we're making some small progress.
#
aaronpk
Scope is usually for limiting what a particular access token can do within what a user is allowed to do, it's not meant to represent limited access by other users
#
GWG
aaronpk: So what is?
#
aaronpk
You probably don't need anything in the spec for that, you can do it internally
#
GWG
That makes sense
#
aaronpk
IMO this is the line that a few of the OpenID connect specs cross over inappropriately
moose3338, alex11 and [jacky] joined the channel
#
Zegnat
I agree with aaronpk, and was planning to use scope just as indieauth has it. For my current tickets I never set scopes because I am not really authorising the user for anything. All the tokens are basically authentication only tokens. I just want to know who is visiting, my website can use that to figure out what you get to do.
capjamesg joined the channel
#
@rowanmanning
I finally wrote about my new fav technology, explaining how to send and receive webmentions on your static site. I'm late to the party but really excited about this! https://rowanmanning.com/posts/webmentions-for-your-static-site/
(twitter.com/_/status/1412687742543273988)
jamietanna and [Rose] joined the channel
#
jamietanna
I'm sure aaronpk wrote a gist for a self-contained endpoint, fluffy, but I can't seem to find it offhand
[fluffy] joined the channel
#
[fluffy]
regarding scopes, yeah, I don’t personally have any particular reason for caring about them beyond just wanting to interoperate correctly.
#
[fluffy]
also it was a convenient place to shove in the “this token is being used as a ticket” without having to like. change my serialization again.
#
[fluffy]
and Publ definitely handles user-level permissions internally rather than trusting the scope of the token.
#
[fluffy]
and of course the initial use case for TicketAuth implies a read scope anyway. I don’t really see any use case for using it with, say, micropub
#
[fluffy]
for that matter, when you sign into Publ, it only requests a ‘profile’ scope as a matter of having *something* in the scope (since the spec requires it) and even if something were to actually provide the profile with the authorization response, Publ doens’t use it; it just parses the h-card from the ‘me’ URL.
#
[fluffy]
incidentally I made a decent amount of progress on adding the ticket grant flow to Publ but then I got distracted by a music project with a tight deadline. Hopefully I’ll have TicketAuth working within a few days.
GoldenEye joined the channel
#
jamietanna
So I've got a ticket receiver up - I've gone for requiring the `issuer` parameter to tell me who's issued the token, so I can then look up their profile information. I've put it as a Ruby POC on Heroku so will share the code + add details to the Wiki shortly
#
jamietanna
Been able to get a token from Zegnat - although as mentioned, I needed to manually add the `issuer` so it didn't work out-of-the-box
#
jamietanna
Zegnat I do see `"me": "https:\/\/www.staging.jvt.me\/",` - is that the expected format for your `me`s?
#
@AndreJaenisch
The other day, I looked at #WebMention servers. The #IndieWeb community wrote a dozen or so clients, but I could o… https://twitter.com/i/web/status/1412712879636234243
(twitter.com/_/status/1412712879636234243)
#
sknebel
... don't write a snarky reply ... don't write a snarky reply ...
hendursa1 joined the channel
#
sknebel
(admittedly that part of the wiki isnt the cleanest, but still, *nothing*?)
#
jamietanna
Updated the wiki with my POC's details :)
#
Zegnat
jamietanna: yes, it sets the me === subject, because I feel like that is the "owner" of the token.
GoldenEye and shoesNsocks joined the channel
#
GWG
Morning all
#
jamietanna
Morning GWG
#
jamietanna
Ah sorry Zegnat I should've been clearer - are the escapes for the slashes expected?
#
GWG
jamietanna: What is next for you?
#
jamietanna
Right now, lunch :D But may look at starting my work to be able to issue tickets from my IndieAuth server
#
Zegnat
jamietanna, I am not escaping slashes myself. If they are escaped, I guess that is because PHP’s JSON module does that
#
Zegnat
Yeah, I just checked, PHP’s JSON adds those. And it is JSON spec compatible to escape forward slashes.
#
Zegnat
php > var_dump(json_encode(["url" => "https://vanderven.se/martijn/"]));
#
Zegnat
string(43) "{"url":"https:\/\/vanderven.se\/martijn\/"}"
#
Zegnat
So aslong as you are JSON decoding, they should disappear on your end again.
#
jamietanna
https://stackoverflow.com/a/10210433/2257038 has a good answer to it - it looks like you can resolve your end as it's not needed to be encoding the slashes (as i.e. Ruby out of the box isn't removing those slashes when I JSON decode)
#
Zegnat
I could probably add that flag. But do note that even the latest JSON RFC still allows escaping forward slashes. So even if I do so, it is not at all guaranteed that every implementation you run into does so.
#
Zegnat
So sounds like a Ruby bug
#
Zegnat
Hmm, not even I-JSON changed anything about that, so for interop they assume that all JSON parsers support escaped forward slashes
jamietanna1 joined the channel
#
jamietanna1
Of the languages I've worked with, I think PHP is the only one that does that by default tho 🤔
[fluffy] joined the channel
#
[fluffy]
forward-slash escaping is necessary to support in JSON because of the need to stop </script> from being interpreted by the HTML parser if the JSON blob is inside a <script> section.
#
[fluffy]
It’s silly that PHP’s JSON encoder escapes *every* forward slash, though
#
[fluffy]
presumably it was substantially easier to write that way
#
[fluffy]
BTW where in TicketAuth is this ‘issuer’ thing documented/being decided?
[KevinMarks] joined the channel
#
GWG
I still think it should be the me property
#
GWG
So, proposal is that the ticket optionally have a me property indicating the identity of the sender of the ticket, where the token endpoint can be discovered
#
GWG
If the property isn't sent, the ticket endpoint should discover the token endpoint at the URL of the resource
#
Zegnat
Is me really the best name there? Because that will be a different me then will show in the token after exchange. Wonder if we end up overloading what me means
#
GWG
Property name aside, does the behavior make sense?
#
GWG
That it is optional and that if not present, discovery is run on the resource instead?
#
aaronpk
There is a PHP flag to stop it from escaping the slashes. I try to use it whenever I can
#
@AndreJaenisch
↩️ Which of those is not a CMS? I want to receive WebMentions by exposing an API endpoint on my domain (with MariaDB and everything), so basically look for a library. I'm okay with http://WebMention.io, but I can do more if all data are under my control.
(twitter.com/_/status/1412783624869584900)
#
@schnarfed
↩️ Ah, you didn't mention you wanted a standalone library. There are lots of non-CMS webmention receivers there, in the service sections, but you're right, not many libraries, probably because receivers generally need to store mentions somewhere, which is implementation-specific.
(twitter.com/_/status/1412785473760546819)
#
@AndreJaenisch
↩️ Yepp. For now, I'll point to http://webmention.io as I move my code towards my own domain. Then, I'll look into fetching all data there and put it into my own database before I write an endpoint. I mean, libraries like PonyORM or Knex can handle multiple database backends.
(twitter.com/_/status/1412787332130951175)
#
jamietanna
fluffy there's a bit more thinking under the question "Where does the ticket endpoint go looking for the token endpoint?"
#
jamietanna
I agree that not using `me` makes sense, and that `issuer` makes more OAuth2-y sense
#
@aaronpk
↩️ You might be interested in this list, there's a handful of different approaches there: https://indieweb.org/Webmention-developer#Handling
(twitter.com/_/status/1412789434886483971)
#
jamietanna
GWG I think that approach sounds reasonable _but_ instead of complicating things for receivers, why not just require i.e. `issuer` to always be sent?
#
GWG
jamietanna: I have no reason specifically
#
jamietanna
I like the option though, it's a good way to do it, especially as we're starting to have differing implementations
#
jamietanna
would be good to hear folks' opinions, other than mine!
#
aaronpk
i should really try to do an implementation of this before saturday
#
Loqi
agreed.
#
aaronpk
btw are folks planning on joining live on saturday to maybe try to work out some more details?
#
GWG
aaronpk: I would like to
#
GWG
I'm set to start the Zoom at 9am Pacific, but can arrange earlier
#
aaronpk
i probably can't join earlier than 9am anyway
#
GWG
I'm offering for any people on earlier timezones
#
Zegnat
If I am around on Saturday, I will definitely hop in a Zoom if one is available
#
GWG
Unless a European wants to turn it on early, I'll handle noon
KartikPrabhu and capjamesg joined the channel
#
capjamesg
GWG I might be around earlier. Happy to turn on earlier if there's anyone who wants to join earlier :)
capjamesg and KartikPrabhu joined the channel
#
capjamesg
What's the best way to mark up a list of search results?
#
capjamesg
In HTML.
#
capjamesg
<ol>s because the search is ordered by relevance?
#
capjamesg
With each result in an li?
lanodan joined the channel
#
GWG
We have the ability to set up breakout rooms
#
GWG
Sorry, re Saturday and side discussions
capjamesg and [Ana_Rodrigues] joined the channel
#
[Ana_Rodrigues]
capjamesg I’d use an ol yeah
[tw2113_Slack_], rockorager and [snarfed] joined the channel
#
[snarfed]
rockorager I assume that >6M POST was a video?
#
rockorager
No, just a random photo from my phone. I was testing from both quill and Sunlit
#
rockorager
After you account for base64 encoding, max image size is ~4mb
#
rockorager
It's just annoying because Netlify gives you nothing when AWS rejects for size limit...you just get no request at all, so you can't even send back a nice error code from inside Netlify
#
rockorager
Quill ends up showing an immediate error, and Sunlit keeps going and then times out with an 'internal server error' after about 10 seconds
Seirdy joined the channel
#
jamietanna
ah that's a pain - I remember seeing tha tin the past when doing https://micropub-media-endpoint-proxy.netlify.app/ and why I made it POST directly to the media endpoint from the browser, rather than via Netlify Functions
#
jamietanna
tis a pain!
#
[snarfed]
jamietanna, unrelated, just fyi your site is doing its wm sending loop again for current posts, eg https://www.jvt.me/mf2/2021/07/o26sj/ and https://www.jvt.me/mf2/2021/07/e2wvz/
#
[snarfed]
totally ok, not a problem, just wanted to let you know
#
rockorager
jamietanna: Checking out your code! Doesn't a file >6mb get kicked back since it's showing up in AWS as file.content?
jamietanna joined the channel
#
jamietanna
aargh sorry about that snarfed - I know what that'll be and will sort it shortly :)
#
jamietanna
rockorager apologies, I misremembered what my stuff actually did! Yes this will hit the same issue :(
#
rockorager
No worries...you clued me in to the lambda-multipart-parser which I wish I had seen a week ago!
angelo and sknebel joined the channel
#
@rowanmanning
↩️ Yeah definitely some similarities, the indieweb wiki has a page on trackback which talks about the issues with it (some of which webmention solves) https://indieweb.org/Trackback
(twitter.com/_/status/1412905560228388864)
[KevinMarks] and [fluffy] joined the channel
#
[fluffy]
Okay I finally got around to reading the discussion of issuer vs. resource on the wiki. I think people might be working cross-purposes on those things… it seems like some folks are using TicketAuth as a means of providing notification about a specific resource becoming available, and some folks are using it as a means of granting the ability to follow a feed or the like.
#
[fluffy]
My expectation of TicketAuth was for the latter case - that I’d be giving people a bearer token that they can use when pulling my feed from my site, rather than giving people a bearer token to access a specific page.
#
[fluffy]
Like I guess what I want my token generation to be for is more of `realm` than `resource`.