corlaezAnd the constrains of gemtext, while limiting, I find they allow me to focus in the content and lifts some of the weight from publishing something up. Just a tiny bit of formating
corlaezbecause even if you make the tinyest, simplest HTML page, chances are the browser has all sorts of gadgets running: js engine, APIs, fingerprinting, stores, etc
corlaezThe one thing about gemini which I just go rogue about is requiring TLS always. I think it is kind of a blunder. For hosting a service over the internet, big YES. but otherwise I can see practical applications of the TLS-less version of gemini being useful
corlaeza critique to gemini (the biggest change since that is that the protocol and gemtext are now separate specs and I think they have made them a little more specific and less ambiguous)
corlaezI don't think the closing the connection critique is fair, the protocol is oriented to the gemtext or file transfer use and gemtext explicitly won't initiate a request when rendering the page (unlike html)
corlaezPerhaps, I am dumb and don't know how expensive the connection opening really is, but if you transfer files and pages that take you enough seconds to read or observe
carrvo[d]In my effort to cleanup and redeploy, I have, for reasons I can elabourate, the pattern `https://example.com/public/user/myuser/profile/index` and I am wondering if there is a nicer term to see than "public" (the rest will remain as is)? Any clever suggestions?
carrvo[d]I can add later a shorter path that resolves (in the background) to what I am configuring now. But, yes, I noticed how long it has gotten by reasons I can elabourate if you wish.
osteophageThanks! I think I have two karma records now, though, since I have a different display name to my username. Or does Loqi know how to match the two?
carrvo[d]Long elabouration: `<resource>` tells Apache that dav_svn will serve the content; `<repo>` tells dav_svn which repo to serve from; `<myuser>` so that multiple people can have their own folder for that particular repo; `<auth-bypass>` so a user webpage and links can be used with IndieAuth without exposing any of their other files; `<file>` for the webpage.
[tantek]aaronpk++ that IETF thread looks frustrating. It's like people are finally getting the desired UX, but absolutely ignoring that it's a solved problem
LoqiIt looks like we don't have a page for "DNS Handle" yet. Would you like to create it? (Or just say "DNS Handle is ____", a sentence describing the term)
sknebel(indieauth strictly speaking is any URL, not domain level, or did that ever change in some recent iteration I'm forgetting about? but the common case is of course totally a domain)
carrvo[d]aaronpk, isn't the IETF thread describing the start of IndieAuth? It is ironic because going down that line of thought contributed to me finding IndieAuth and I am notoriously bad at finding things on the internet.
carrvo[d]Do you want to know what else is ironic? I was really close to making https://github.com/OpenIDC/mod_auth_openidc compatible with IndieAuth! (I did not want to dive into JWKS...)
carrvo[d][edit] Do you want to know what else is ironic? I was really close to making https://github.com/OpenIDC/mod_auth_openidc compatible with IndieAuth! (I did not want to dive into JWKS...)
aaronpki'm kind of tempted to go bring a draft into OpenID that describes returning the user ID in the token response like IndieAuth so there's a way to do OIDC officially without JWKS or an extra request to the userinfo endpoint
carrvo[d]I think my specific issue was that the JWT needed to be signed and verified, and that JWKS was the easiest way to tell the module the information to verify. Anyway, I have the experiment stored if it of interest sometime.