barnabyI just ran into issues setting up nextcloud caldav and carddav on hostinger, because they don’t allow rewriterules or PHP files in .well-known for some reason. apparently it’s not uncommon for shared web hosts, but as usual it’s almost impossible to figure out which ones have this issue and which don’t
barnabyif it’s widespread then it’s a huge argument against webfinger and any other protocols which rely on .well-known IMO. I’m surprised I haven’t seen it discussed anywhere before
[tantek]We must keep documenting real world examples like this so we can keep pushing back at IETF and other places when people keep making up new .well-known things
barnabyI added instructions and a .htaccess code snippet for testing .well-known support on apache shared hosts. hopefully we can get some more data on this to a) help people choose web hosts and b) provide evidence that .well-known simply isn’t accessible for a large swath of web hosting companies
barnabysuperkuh: I moved away from a VPS after years of hassle, expense and admin tax. nobody should be required to manage a VPS in order to support webfinger
barnaby(or zero-config CAL/CARDDAV setup, which is what I was actually trying to do when I found this limitation. fortunately there were workarounds for that — not so for webfinger afaik)
[tantek]capjamesg, aaronpk is probably more familiar with the actual arguments that folks at IETF etc. make to push for using .well-known because I'm sure he hears them all the time.
aaronpki've started to have good luck with the argument against .well-known that often times the root domain of a website is run by the marketing team at a company and isn't "owned" by the ops team that is providing whatever service is being discovered
[tantek].well-known << Marketing vs ops: another reason it is bad to depend on .well-known in practice: <blockquote>often times the root domain of a website is run by the marketing team at a company and isn't "owned" by the ops team that is providing whatever service is being discovered</blockquote>
Loqiok, I added "Marketing vs ops: another reason it is bad to depend on .well-known in practice: <blockquote>often times the root domain of a website is run by the marketing team at a company and isn't "owned" by the ops team that is providing whatever service is being discovered</blockquote>" to the "See Also" section of /.well-knownhttps://indieweb.org/wiki/index.php?diff=89190&oldid=89189
[manton][snarfed] Just linked to your blog post, but just an extra shout-out here that it’s a really useful grid. I’m still very interested in Nostr but I do worry about it being exclusively WebSockets. It’s clever but can it really even be IndieWeb-friendly without some kind of basic HTTP GET layer?
barnaby[snarfed]: speculative question about bridgy fed: are the .well-known redirects absolutely required to point to bridgy fed (e.g. due to having dynamic content on) or could I in theory host a static version of whatever bridgy fed is serving there on my web host, which allows static files in .well-known but no PHP or redirect rules?
[snarfed]thanks [manton]! yeah websocket is different, but it's still kinda half HTTP, not something totally different like gRPC or BitTorrent etc. I wondered about it too, but it was straightforward to ramp up on, and libraries are widespread and mature
[snarfed]the main concern seems more ops than development: you have to maintain long-lived connections, which is sometimes a bit trickier to configure servers for well
[snarfed]barnaby yeah you could probably do it with static files! feel free to look at the .well-known responses for an example BF user and try. let me know if it works out!
barnabythanks! got a fair amount of work to do on my site before it’s ready for bridgy fed set up, but knowing that it might still be possible (without changing web hosts again…) is a good motivation!
[tantek]does anything else IndieWeb related use WebFinger besides Mastodon? If not, then we should document that limited scope explicitly rather than saying "for example, Mastodon"
barnabywebfinger and nodeinfo are the two “fediverse” .well-known endpoints I’ve seen, I don’t have a good overview of exactly how required they are for what functionality though
[tantek]barnaby, that placing of "fediverse" in quotes is exactly why I want to document them as "only" a Mastodon thing until people provide additional specific examples which we can then also document, instead of making it sound like Mastodon is just one example of many
[tantek]and frankly, enough other folks are going to code it that way that it's going to make it a defacto required thing to support (at least a redirect from such paths)
[snarfed]with conneg, you can guess that URL, and you may sometimes get redirected to the right actor URL, but only sometimes, and that "guess and assume" heuristic doesn't give me as an implementor anywhere near enough confidence to use it
[tantek]"need for webfinger is to find an AP actor URL" and if we keep asking, for what human use-case, I believe we eventually end up at "human-usable URLs"
[tantek]my point is, we should treat .well-known as only required for "legacy" or "compat" support with Mastodon (and the others you listed), not as an example to build upon
[snarfed]btw of the handful of non-Mastodon implementations I've tried in the last few mins - Guppe, Pleroma, Akkoma, Firefish (nee Misskey I think?), Hubzilla - only Hubzilla redirects @ URL requests with conneg to the AP actor URL
[snarfed]I'm all for a different standard for resolving @-@s to AP actors! and I have no particular love for .well-known. but if you want to interop with current fediverse/AP instances, I guess I disagree that we should assume "they don't need Webfinger except for a few exceptions." that's not true based on both my experiments just now and my experience banging my head against interop with many more existing implementations
[tantek]right, and this is why I'm actively auto-linking @-@s without using webfinger, as proof that it is "good enough" and that implementations will adapt to support that
[snarfed]so then the machine-usable equivalent, eg resolving to an AP actor, would be that an AS2 conneg request to the same /@username URL either returns or redirects to that user's AP actor?
[snarfed]lol, I'm just trying to keep track of what we're talking about. I started out at, how much of the (AP) fediverse uses/needs Webfinger, and what do they need it for: resolving @-@s to AP actors
[snarfed]unrelated, anyone know of a good reference for "every indieweb object (post, person, etc) is identified by a URL"? looking for a link to cite in the comparison table
[KevinMarks]One extremely simple solution is with a rel header for the template to map back and forth between user@host and url. rel="accountmap" template="https://example.social/@{user}"
barnaby I just ran into issues setting up nextcloud caldav and carddav on hostinger, because they don’t allow rewriterules or PHP files in .well-known for some reason. apparently it’s not uncommon for shared web hosts, but as usual it’s almost impossible to figure out which ones have this issue and which don’t
capjamesg Why is .well-known adopted?
[tantek] here's a recent example of this discovery debate: https://github.com/privacycg/proposals/issues/39
Loqi ok, I added "Marketing vs ops: another reason it is bad to depend on .well-known in practice: <blockquote>often times the root domain of a website is run by the marketing team at a company and isn't "owned" by the ops team that is providing whatever service is being discovered</blockquote>" to the "See Also" section of /.well-known https://indieweb.org/wiki/index.php?diff=89190&oldid=89189 
[manton] [snarfed] Just linked to your blog post, but just an extra shout-out here that it’s a really useful grid. I’m still very interested in Nostr but I do worry about it being exclusively WebSockets. It’s clever but can it really even be IndieWeb-friendly without some kind of basic HTTP GET layer?
[KevinMarks] Rather than @-@, how do you resolve the profile url to an app actor?