#dev 2021-06-19

2021-06-19 UTC
[tantek], samwilson, Ed, shoesNsocks, jeremy, jjuran, tonz, jeremycherfas, hendursa1, mikeputnam, shoesNsocks1, hendursaga, capjamesg, [jacky] and pepperoni joined the channel
#
@edent
Yes, because Pingbacks and WebMentions have been embraced willingly - with no problems with spam or harassment…
(twitter.com/_/status/1406305437016805379)
hendursaga and [tw2113_Slack_] joined the channel
#
sknebel
https://w3c.github.io/multicast-cg/multicast-cg-charter.html has some hints towards why W3C and not IETF (which I'd have expected)
#
aaronpk
I was wondering why not IETF too
#
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.
#
aaronpk
nofollow has nothing to do with indieauth or relmeauth really
#
aaronpk
indielogin.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
#
aaronpk
the URL you sign in as will point to the micropub endpoint, there isn't a way to point to more than one
#
aaronpk
so benatkin.com can have the micropub endpoint at runlog.benatkin.com and nothing will care about that
#
aaronpk
but 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
#
aaronpk
you'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
#
mgdm
love 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?
#
sknebel
not past the plaintext vs html in the spec, but there is an issue somewhere about that...
#
sknebel
probably in micropub-extensions
#
aaronpk
i've experimented with that in quill
#
aaronpk
to specify text vs markdown
#
aaronpk
but it gets messy as you might imagine, for example jupyter notebooks...
#
astralbijection[
could it be specified with something like a content-type parameter?
#
aaronpk
yes but that's not really the problem
#
astralbijection[
what is the problem?
#
Loqi
The problem is that when you ask what is the problem, you need to be more specific https://indieweb.org/problem
#
aaronpk
not 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?
#
aaronpk
and what should a client do if it sees the server supports content types that it doens't know about?
#
astralbijection[
oh, that makes sense
#
aaronpk
keep 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
#
sknebel
!xkcd standards
#
batkin[m]
Not all HTML is going to going to work for all blogging engines and templates either. Less of a problem but similar.
#
sknebel
I think this is something worth experimenting with, even though aarons caveats of course apply.
#
aaronpk
i agree which is why there's an easter egg in quill to enable this :)
#
sknebel
sigh, I cant find the existing discussion about this
#
aaronpk
me either
#
sknebel
I guess. not quite what I remember, but close enough
barnaby joined the channel
#
barnaby
Regarding 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
#
barnaby
I think some of the UI issues surrounding multiple content types could be reduced by support for previewing of some sort
#
barnaby
that way, users can get realtime feedback about how what they’re typing will get interpreted *by the server it’ll be posted too*
#
aaronpk
previewing would be cool for sure but that opens up a whole new can of worms :)
#
aaronpk
i think there was some discussion about that recently though
#
barnaby
yeah, I bought it up a week or so ago
#
aaronpk
jan 2020
#
aaronpk
er, hun
#
aaronpk
i 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
#
barnaby
the suggestion of implementing previewing by posting drafts has the additional benefit of working as an autosave
#
barnaby
I’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
#
barnaby
I’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
#
barnaby
the difficulty becomes how to display them, as you can’t use an iframe
#
aaronpk
the only way to really preview a post is to see it on the actual website
#
aaronpk
which is why i did draft posts
#
barnaby
perhaps a draft endpoint could return a rendered_html property which the authoring UI could use for previewing
#
barnaby
aaronpk: sure, but that’s not the same UI as real-time previews
#
barnaby
a 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
#
barnaby
less “this is exactly how your post will look”, more like “this is how the server you’re posting to interprets what you’re typing”
#
aaronpk
i feel like the value of that is going to be pretty limited given how complicated it would be to implement it reliably
#
barnaby
what problems do you forsee?
#
barnaby
preview markup returned from the server interfering with the authoring UI?
#
aaronpk
what 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?
#
aaronpk
obviously 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
#
barnaby
you can use an iframe to sandbox content from a string, not a URL
#
barnaby
so 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
#
aaronpk
you're going to want _some_ css there so it's not just browser default styles
#
barnaby
that way the server can choose whatever CSS, js etc it wants, without danger of interfering with the client
#
aaronpk
if 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
#
barnaby
cool, <iframe> has a bunch of interesting security attributes https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
#
Zegnat
I 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
#
barnaby
the iframe could use the sandbox attribute to prevent scripts from loading but allows CSS, fixing the main presentation issue
#
Zegnat
Would 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
#
barnaby
I can’t think of many use cases for letting the preview run scripts
#
barnaby
the MDN link covers it pretty well. it seems quite flexible. hopefully browser support is good
#
barnaby
clients could also just disable previewing in browsers which don’t support sandboxing
#
Zegnat
Sites 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!
#
barnaby
then there’s the question of how to deal with multipart uploads
#
barnaby
either 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
#
barnaby
maybe I’ll put together a minimum viable implementation — would be a good first test for my micropub library after all
alex11 joined the channel
#
barnaby
hmm 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
#
barnaby
so potentially even JS could be safely included in a preview
#
barnaby
huh, this would be ideal, but its existence seems suspect https://developer.mozilla.org/en-US/docs/Web/HTML/Element/portal
#
barnaby
and if it supported srcdoc, but I guess data URIs could do the same thing
#
barnaby
hmm and it’s really for navigation, so not quite the same thing
vilhalmer joined the channel