batkin[m]I have an IndieAuth question. Let's say I have 5 different tiny micropub websites on subdomains. How do I sign into them using `IndieAuth.com`? If I use a rel="me" link to GitHub on each site that would work except I can only have one rel="me" on GitHub because it changes rel="me" to rel="nofollow" in the profile page markdown.
aaronpkindielogin.com will look for additional links in the bio on github and twitter so you can use it with more than one. i don't think that logic is in indieauth.com though
batkin[m]Ah, I see. Yeah, it appears indieauth.com only does the *website* link in the github profile. I thought it was because of rel="me" but it seems it just grabs that.
batkin[m]I want to sign in as benatkin.com from, for example, runlog.benatkin.com - and have the micropub endpoint be on runlog.benatkin.com since it's a different server. Any way to do that?
aaronpkbut if you wanted to have 5 different micropub endpoints at a.example.com b.example.com c.example.com etc, there's no way to have example.com point to all of them
batkin[m]I see. Yeah a proxy is something to consider. It could also check the for Micropub channels and make a list of them. I might prefer separate Micropub endpoints in which case a proxy of sorts for IndieAuth might be the ticket.
astralbijection[I have a micropub endpoint and I'm thinking of supporting different content types (plaintext, markdown, html fragment, jupyter notebook among others). Is there a way to specify the content type in micropub?
aaronpknot finding any previous notes on this, but for example "markdown" isn't actually a format, it's a name for a whole bunch of slightly different formats, so what exactly does it mean if a client and server claim to support markdown?
aaronpkkeep in mind the main goal of micropub is to have interoperable clients and servers, it's not meant to be just a recipe for how to build a blogging backend
barnabyRegarding micropub content types: weren’t we recently discussing how many clients/servers support HTML authoring vs plain text? we could look at how implementations are handling those content types first
aaronpki do use the "draft" idea for this too though, where i'll post a draft post from quill so that i can double check it on my site before making it public
barnabyI’ve had to re-create posts from scratch a couple of times because I accidentally swiped “back” while authoring them, and the textfield form control I use doesn’t preserve content like regular form elements
barnabyI’m not familiar with the draft extension, but if it returns a URL containing the draft, then micropub-authenticated requests could be sent from the authoring UI to get the contents
barnabya real-time preview doesn’t have to show *exactly* how the post will look in-context, but could show the results of server-side transformations e.g. markdown, autolinking etc
aaronpkwhat css defaults would a web-based client use to display the post? quill uses bootstrap, other clients use other css frameworks. what about an iOS client? would it include an embedded web view?
aaronpkobviously any client would have to sanitize the crap out of the HTML returned by the server to avoid xss and other issues, so that is also a barrier to building clients
barnabyso the client sends the micropub request either to a preview endpoint, or with mp-preview or whatever, the server returns an HTML string, which the client sets as the srcdoc of a preview iframe
ZegnatI have not touched that part for a bit, but part of me feels like window.parent lets your JS break out of srcdoc. So you willl still want to do xss protection being a client. Unless browsers ship stronger protections now than they used too
ZegnatWould need testing to make sure that applies when the contents is loaded from srcdoc, but yeah, might work. I do not remember the sandbox attribute from when I last looked at it
ZegnatSites might be using JS for things like code syntax highlighting. Rendering of math also comes to mind. Requirement for JS for rendering posts will depend a lot on particular sites. But this could definitely be worth looking into!
barnabyeither ignore them, showing placeholder content, storing the file in a temporary location, or including it in the preview as a data URI all come to mind as potential solutions
barnabyhmm apparently if sandbox is used without specifying allow-same-origin, the iframe will be treated as being from a different origin, and shouldn’t have access to the parent