#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.
#aaronpknofollow has nothing to do with indieauth or relmeauth really
#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?
#batkin[m]I was looking at signing in as runlog.benatkin.com as an alternative but the ideal is to just have one website that I sign into
#aaronpkthe URL you sign in as will point to the micropub endpoint, there isn't a way to point to more than one
#aaronpkso benatkin.com can have the micropub endpoint at runlog.benatkin.com and nothing will care about 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
#aaronpkyou'd have to do that yourself by having a sort of proxy at example.com route the request to the right backend micropub endpoint
#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.
j12t, j12t_ and shoesNsocks joined the channel
#mgdmlove it when your static site generator changes how it sorts posts without calling it out in the release notes
astralbijection[ joined the channel
#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?
#sknebelnot past the plaintext vs html in the spec, but there is an issue somewhere about that...
#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?
#aaronpkand what should a client do if it sees the server supports content types that it doens't know about?
#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
[jacky] joined the channel
#[jacky]notes that markdown _can be_ standardized via CommonMark
#sknebelI guess. not quite what I remember, but close enough
barnaby joined the channel
#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
#barnabyI think some of the UI issues surrounding multiple content types could be reduced by support for previewing of some sort
#barnabythat way, users can get realtime feedback about how what they’re typing will get interpreted *by the server it’ll be posted too*
#aaronpkpreviewing would be cool for sure but that opens up a whole new can of worms :)
#aaronpki think there was some discussion about that recently though
#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
#barnabythe suggestion of implementing previewing by posting drafts has the additional benefit of working as an autosave
#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
#barnabythe difficulty becomes how to display them, as you can’t use an iframe
#aaronpkthe only way to really preview a post is to see it on the actual website
#barnabyperhaps a draft endpoint could return a rendered_html property which the authoring UI could use for previewing
#barnabyaaronpk: sure, but that’s not the same UI as real-time previews
#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
#barnabyless “this is exactly how your post will look”, more like “this is how the server you’re posting to interprets what you’re typing”
#aaronpki feel like the value of that is going to be pretty limited given how complicated it would be to implement it reliably
#barnabypreview markup returned from the server interfering with the authoring UI?
#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
#barnabyyou can use an iframe to sandbox content from a string, not a URL
#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
#aaronpkyou're going to want _some_ css there so it's not just browser default styles
#barnabythat way the server can choose whatever CSS, js etc it wants, without danger of interfering with the client
#aaronpkif you think it'd work, it'd be interesting to write up an implementation guide for both sides of it to see what it would actually take
#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
#barnabythe iframe could use the sandbox attribute to prevent scripts from loading but allows CSS, fixing the main presentation issue
#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
#barnabyI can’t think of many use cases for letting the preview run scripts
#barnabythe MDN link covers it pretty well. it seems quite flexible. hopefully browser support is good
#barnabyclients could also just disable previewing in browsers which don’t support sandboxing
#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!
#barnabythen there’s the question of how to deal with multipart uploads
#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
#barnabymaybe I’ll put together a minimum viable implementation — would be a good first test for my micropub library after all
alex11 joined the channel
#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
#barnabyso potentially even JS could be safely included in a preview