vika_nezrimayasorted sets are really built for this kind of thing, but I think I might need some server-side pagination to make it blazing fast enough for feed views
vika_nezrimayaI mean, with 100000 feed items it takes 0.7 seconds to get the whole feed, but it scales linearly and I don't see getting 100k posts in forseeable future
vika_nezrimayascaling linearly since ZREVRANGEBYSCORE is O(log(n)+m), where n is the cardinality of the sorted set and m is the number of items requested
vika_nezrimayato a Micropub client that will be an implementation detail, to me it'll be a way to really optimise pagination - I'll be able to simply request limit+1 items every time and return posts[limit]'s timestamp (which is its ZRANK) as a pagination token
ZegnatI think I have two points to discuss on that one: 1) must the extra check always be done or can we safe the work for clients in some cases (e.g. where new profile URL is a subpath of the original profile URL?) and 2) must we still forbid the domain from changing when different URLs have a way to be checked.
sknebelI don't feel particularly comfortable defining a "this has to be safe" exception that won't break a realistic scenario, so given the (IMHO) little gain I'd rather err on the side of checking "too often"
ZegnatI guess most of my ponderings are in the "what effects has this throughout the spec" category. I have no problems with making clients redo discovery on the returned profile URL when it is different from the originally discovered profile URL. That seems fine to me.
ZegnatAgreed, it is not what the change set out to solve. But I like it if we can simplify any parts of the spec by having as few exceptions or alternative behaviours as possible. But completely fine with opening a seperate ticket for it after this gets merged.
[manton][sknebel] Academic/corporate environments can’t use subdomains? I agree we don’t want to be too restrictive, but again I worry about making IndieAuth much more complicated than it already is.
[manton]If someone is using a library that handles everything, great, but if someone is rolling their own implementation, expecting them to follow 10 redirects and re-download the HTML to check links, etc… It’s a lot. 🙂
[fluffy]And sknebel I agree, reducing HTTP transactions gets to be a micro optimization after a certain point, and micro optimizations are bugs in disguise
[fluffy]Most of the complexity in my implementation comes from having to verify the URL itself due to redirections. Checking the endpoint matching is trivial, and reuses a function that already existed for the initial discovery.
[fluffy]Also, if IndieAuth cannot be trusted on shared domains then it cannot be trusted, as there is no way to know if someone has implemented it on a shared domain.
[manton]If IndieAuth didn’t support shared domains, it wouldn’t be an issue. But I’m happy to drop the issue… Just wanted to voice my concern instead of ranting on the Zoom call about it. 🙂
[fluffy]Supporting shared domains is incredibly important IMO. The vast majority of academic homepages are tilde pages; university IT does not hand out subdomains for homepage hosting, and most students aren’t going to set up a dedicated server.
sknebeland since you can't technically *block* shared domains, you'd rely on every implementation and documentation always warning users about not to use it in such situations, which IMHO is a terrible idea for a security feature
ZegnatI think the argument there has always been that those students should be enabled to get a domain (which they could setup to forward to their tilde page). Because that way even when you quit the university, your identity moves along with you.
ZegnatBut as a folder-user myself, I totally see the use-case. I have always been using IndieAuth for my sub folder. And most of the time there are no problems. The fact that this opens up for imitations is a concerning though.
[fluffy]Even if they can it requires more technical acumen. And they’d still need to be able to host the profile page in such a way it still canonicizes as the subdomain.
[fluffy]Which means ensuring a temporary redirect, and validating that is way more complex code-wise (and still needs to be done, and is already in the spec)
[fluffy]I would rather see more complexity on clients, which can use existing libraries and have more validation performed on them, than on users, who just want a dang webpage.
[fluffy]And verifying that the endpoint matches is trivial and gives you more security guarantees on its own than verifying the canonical URL on its own
[fluffy]Honestly the whole temporary vs permanent redirect thing is annoyingly complex, and verifying the domain doesn’t change is annoyingly complex, and neither of those do anything to guarantee endpoint integrity.
ZegnatThe temporary redirects are there so you can have something as your profile URL even if that is not the resource where the auth endpoint is on. Which I think is the proper HTTP way of using that. Allowing you to switch systems without switching profile URL.
[tb]Don't want to send the popup on a tangent for this so I'll post here while I remember — is there a reason why a defacto `read` scope hasn't been defined alongside `create`/`media`/`update`/`delete` here in https://indieweb.org/scope or used in any of the implementations listed out there?
[tb]I suppose there's not really anything you'd want to do against the Micropub query endpoint though without also wanting to do `create`-type things down the line though
[snarfed]you can get public posts from the site (h-feeds etc), but not drafts, private posts, feed locations aren’t standardized or guaranteed to contain all posts, etc
ZegnatI was discussing that with voxpelli over coffee last week. Where he brought up the - to me unknown - BREAD over CRUD debate. As in CRUD rules do not cover everything, you want BREAD, which includes "browse" as an action. http://paul-m-jones.com/post/2008/08/20/bread-not-crud/
jamietannaI guess you wouldn't necessarily introspect JWTs, as often Authorization Servers would issue a JWS rather than a JWE, so you'd be able to inspect the claims without introspecting it
hirusi[m]Not sure, aaronpk. I can't comment on what the industry standard/defaults are, just that it confused me and would like to see it ironed out :)
GWGhirusi[m]: There is obvious overlap between Micropub and IndieAuth as Micropub uses IndieAuth, but we weren't focused on anything Micropub specific today
ZegnatShould we have opened a separate ticket for the changes needed around the auth endpoint verification step, aaronpk? Or is just the TODOs in the notes enough?
ZegnatWhere do I store the secret? Selfauth is stateless, so would have to be in the state. But then you want it to be encrypted and there is not really anything in out-of-the-box PHP 5.6 that I would want to use for that encryption...
aaronpkbut also yes the pkce code verifier can't be returned in plaintext as part of the authorization code otherwise that defeats the protection that pkce provides
[dmitshur]I see. To clarify though, I used it because I didn't understand a comment, not that I disagreed with it. A guess a comment would've been more clear.
ZegnatBut for those signatures Selfauth only needs 1 random secret (stored in APP_KEY) that gets set at installation. PKCE would require new randoms for each request, which does have storage requirements.
[fluffy]with PKCE can you generate a new secret by hashing the APP_KEY along with something that's immutable throughout the transaction? Or is that not considered secure enough?
sknebelGWG: ah. I think the interesting ones are in PHP 7, BUT a) worth checking if wordpress is using them in wp_generate_password and b) there is a 5.6+ polyfill by paragonie: https://github.com/paragonie/random_compat
ZegnatSo my mind kinda gave up and started to wonder if it is useful to try and figure out a solution. Or if I should do a PHP7+ implementation where I also merge in Mintoken.
ZegnatNote that scopes were not even included in the first version of Selfauth, because it was just for authentication. So in a world where IndieAuth is moving to even closer to zero stand-alone token endpoints than today, maybe Selfauth is moving towards overall deprecation anyway...
ZegnatI am just wondering what people use on the wider IndieWeb where they get away without a token endpoint. Telegram, indieweb.org, and webmention.io? Is that it? As soon as you start wanting to experiment with Aperture or Quill you are going to need tokens, and a bunch of other endpoints.
ZegnatThere is also a bit of eat-what-you-cook in here. The more I am thinking of moving away from Selfauth on my own site, the less likely I will be to do any upkeep on the code. And it already feels like many of the other collaborators on it have dropped off too
Zegnataaronpk: my own site is static, so probably not integrated. But I want to switch to something that integrates the token endpoint and is written in modern PHP
ZegnatWhatever I end up building will probably still be single user. But I am planning to deploy with Dokku, so it *may* end up having a one-click Heroku deploy thanks to that.
ZegnatBut if you expect indieauth.com alternative to include relmeauth, you might be in for a longer wait, aaronpk. Not sure who wants to take on that pain
ZegnatThat is something I have been thinking about a lot. But I am not sure what I want to swap password logins with. For instance, I got rid of email on my phone. So I cannot just email a link to myself.
ZegnatAnother reason why I want to branch away from selfauth is testing more of that sort of stuff for login. I think Selfauth was great for doing what it does when it was written: dump it on any PHP host you happen to be using and it enables login to the indieweb.
vika_nezrimaya So, I just realized that my feed problem can be solved with Redis' sorted sets
jamietanna[m] Aaronpk et al for the IndieAuth session later - what are your thoughts on adding https://github.com/indieweb/indieauth/issues/33 to indieauth-next? Thinking about making it so we can use existing OAuth2 clients where possible
Zegnat I am still trying to figure out https://github.com/indieweb/indieauth/pull/53 in my head. I would love a whole session on just that ticket, hahaha
aaronpk ok i have a rough agenda for the topics today, i ordered the items here https://github.com/indieweb/indieauth/milestone/1
[schmarty] ponders a "scale of exclusion"
Loqi CRUD refers to the ability to Create, Read, Update and Delete comments and posts https://indieweb.org/CRUD
[dmitshur] Hi sknebel. I saw a notification about a question from you on GitHub, but can't see that message now.
@pixelcrook Testing webmentions on my new site. https://samuelhorn.com/new-personal-site-powered-by-vue-and-gridsome/ (twitter.com/_/status/1297303624801046531)