#dev 2018-09-15

2018-09-15 UTC
snarfed1, snarfed, armegeden15 and [manton] joined the channel
#
[manton] I'm going to experiment with mp-photo-alt. I think it'll be the least disruptive change for now.
snarfed, sknebel, Kaja, Zegnat, Kaja_ and renem joined the channel
#
@skye_mackinnon ↩️ @carole_mortimer Love it! Featured your post here https://www.twinesocial.com/skyemackinnon/rt-iartg-eartg-asmsg-indieauth/233527389 (twitter.com/_/status/1040790871992676354)
Manolis3, Orbstheorem13, leg, Japje8 and jeremych_ joined the channel
#
vanderven.se martijn edited /Micropub-brainstorming (+1441) "/* Brainstorming */ Add yesterday’s discussion and proposal for photo alt text in form-encoded post bodies" (view diff)
#
Zegnat !tell [manton] I have documented yesterday’s brainstorm on the wiki, please expand with your concrete usecase and anything else you can think of :) https://indieweb.org/Micropub-brainstorming#Alternative_text_for_photos_in_form-encoded
#
Loqi Ok, I'll tell them that when I see them next
Yoyo1 and [Tom_Morris] joined the channel
#
[Tom_Morris] my site now has bidirectional rel-me links to mastodon.social
[keithjgrant] joined the channel
#
[keithjgrant] !tell manton I’d love to help by implementing alt text in Omnibear. Image support is one of my next to-dos and alt text seems an essential part of that to me.
#
Loqi Ok, I'll tell them that when I see them next
naftulikay joined the channel
#
Zegnat [keithjgrant], does Omnibear not already support posting JSON bodies?
#
[keithjgrant] Oh, that discussion was only about form encoded? Is the json structure for alt already figured out?
#
[keithjgrant] Hey, Quill supports alt text! For some reason I thought this was still an un-addressed problem
#
sknebel alt text in mf2 parsing isn't quite finished, you might have been thinking of that
#
sknebel (which is something I should follow up on, now it's been used at least a bit)
#
Zegnat Micropub I think is using the proposed mf2 json standard for alt
[eddie] and jackjamieson joined the channel
#
jackjamieson !tell snarfed BTW, I followed up on Moa's removal of @ mentions to Twitter and got a bit more information https://github.com/foozmeat/moa/issues/53#issuecomment-421427659
#
Loqi Ok, I'll tell them that when I see them next
#
Loqi [foozmeat] @jackjamieson2 I can't point you to a specific rule. The other cross-poster was this one https://crossposter.masto.donte.com.br/ You can read about the block at https://masto.donte.com.br/@crossposter/100479477531222745
kiranos_, jeremych_, xarian0, eli_oat, TripFandango, bzoz11, knocte19 and guntbert10 joined the channel
#
boffosocko.com uploaded /File:to_come.PNG "Example of TK editorial mark in the Medium.com user interface. https://indieweb.org/File:to_come.PNG"
#
boffosocko.com created /TK (+826) "stub, Medium example" (view diff)
#
boffosocko.com created /to_come (+16) "redirect to TK" (view diff)
mudpuppy1, ben_thatmustbeme and [manton] joined the channel
#
[manton] [keithjgrant] Yep, the spec describes how to support alt for JSON already, so it's really just a form-encoded issue.
#
Loqi [manton]: [keithjgrant] left you a message 4 hours, 35 minutes ago: I’d love to help by implementing alt text in Omnibear. Image support is one of my next to-dos and alt text seems an essential part of that to me.
#
Zegnat Huh. Did my tell not go through to [manton]? Did I leave it in a wrong channel? :/
[keithjgrant] joined the channel
#
[keithjgrant] Gotcha
#
Zegnat Eitherway, in case you hadn’t seen it, [manton]: I documented the discussion on the wiki
#
[keithjgrant] Hey, any static site folks around? Do you do anything for image hosting? I've got mine working, but I'm concerned adding too many images to my git repo will eventually slow it down too much.
#
[keithjgrant] I've had that problem with images in git before
#
[keithjgrant] (specifically images posted via micropub)
#
sknebel you could look into git lfs?
#
[keithjgrant] Ooh, interesting. I’d forgotten about that
#
[keithjgrant] Will my micropub server need to be aware of lfs, or can it just continue to use the repo as normal?
jjuran joined the channel
#
sknebel not sure
#
[manton] @Zegnat Excellent, thanks for documenting it! I'm looking over the wiki now.
#
Zegnat In the brainstorming section. would be nice if you could expand with some reasoning behind it. But this way there is somewhere to point people if you start experimenting :)
#
[manton] Looks good.
#
[manton] I'm going to implement it in Micro.blog exactly as you have it written up. Captures the discussion well.
#
[manton] And I can update the wiki after that.
#
sknebel what was the reasoning for not using json for requests with alt text?
#
Loqi It looks like we don't have a page for "reasoning for not using json for requests with alt text" yet. Would you like to create it? (Or just say "reasoning for not using json for requests with alt text is ____", a sentence describing the term)
#
[manton] @sknebel There are some servers that might not support JSON. I don't want to break current compatibility with them or add a preference for this, at least not right now.
#
Zegnat One of those things where it is sad you can’t ask the server what it supports
#
Zegnat There is HTTP error 415 if you send a request body of a content-type that isn’t supported. But there doesn’t seem to be a way to check with the server whether a certain type is supported before trying? Am I missing some crucial HTTP header?
#
GWG Query the config?
#
aaronpk I think there is some brainstorming around this in micropub query
#
Zegnat I didn't check that yet. Was sending myself down a HTTP spec rabbit hole first ;)
#
Zegnat Saved by the family though, we're heading to town for the lights festival. Brainstorming later. Cheers.
#
sknebel you could just try json once and see if it throws an error or not
#
sknebel extending form-encoded just so you never have to consider JSON seems weird to me
#
sknebel especially if there's no data about if it's actually an issue
Guest44066 joined the channel
#
tantek___ sknebel, "no data about if it's actually an issue", are you doubting there are micropub clients and/or servers that only support form-encoded requests? that seems like a reasonable assumption based on folks implementing only as much as they need for their use-case, and there are simple post-only use-cases
#
sknebel I'd be curious how the numbers are among mantons users (where I'd assume most use a few common implementations, WP and Known (?)) and if it's truly necessary to restrict the app to that entirely because of those that don't or if a detection approach wouldn't work too
#
sknebel otherwise, it shifts the question to next desired feature that doesn't fit the current form-encoded format, and it seemed very intentional to me that you guys did not make the two equally powerful
#
sknebel (if detection turns out to be impossible and there's an argument to always use form-encoded that seems like a failure of that design then)
#
sknebel I'd personally guess that the app could quite reliably on first post to a new endpoint try a json-based request, and fall back to form-encoded on failure
#
tantek___ there was only partial intention, and nothing related to alt/img
#
tantek___ that is, we decided create-only was an ok limitation for form-encoded, and Update, Delete, Undelete would be ok to be JSON-only
#
Zegnat I think alt texts are an ok extension to form-encoded (and multi data) because those formats already allow posting photos. Opening up the extra accessibility option is nice.
#
tantek___ more than nice, it's good design and the right thing to do
#
tantek___ and yes, if we find any other additions to "create" for Micropub, we should make them in both form-encoded and JSON
#
Zegnat One feature that is currently JSON only (and maybe rightly so) are rich check-ins. Can't have embedded h-cards in form-encoded.
#
sknebel and content marked explicitly as HTML
#
Zegnat Though that is a great reason for people to implement accepting JSON
#
aaronpk Embedded objects were another thing intentionally JSON only
#
aaronpk And HTML, since that requires a nested key in microformats JSON
#
Zegnat Yeah. And I'd say they should stay JSON only.
jjuran joined the channel
#
aaronpk I also think that HTML is good to restrict to JSON since handling HTML input has a bunch of security considerations that come up and it's good to force people to be really intentional about accepting HTML content
#
sknebel an extension also adds another potential difference between servers
[manton] joined the channel
#
[manton] That has been my approach with our Sunlit app. It has to send HTML, so it requires a JSON endpoint. But it has always been there so wasn't a compatibility-breaking change.
#
sknebel e.g. right now, the wordpress plugin supports alt text in JSON syntax
#
[manton] I have no stats on this, but I get the impression that if someone wants to roll their own quick Micropub endpoint, they start with form-encoded. It's just much simpler.
#
sknebel if the app detects JSON and uses it where available, it can post alt text to it
#
sknebel if it uses form-encoded with an extension, now users have to wait until it learns that extension
#
[manton] @sknebel To be clear, Micro.blog sends XML-RPC to WordPress, so WordPress doesn't factor into the way I think about things.
#
sknebel how does it send replies etc then?
#
dev.lahacker.net edited /Post_Types (+0) "Redirected page to [[posts#Types of Posts]]" (view diff)
#
sknebel but ok, replace wordpress with any other endpoint implementation
#
sknebel (I personally recommend people write a JSON-based endpoint first and convert form-encoded to JSON, but it's obvious not everyone is going to do that, which is why I prefix all this with "if detection can work reliably")
#
[manton] It doesn't currently send replies like that. If we start doing that, yeah, Micropub would be more full-featured than XML-RPC.
#
[manton] Yeah, detection would be nice. If a convention using HTTP or q=config comes up, I'd support it.
#
sknebel you don't think trying JSON and fallback works?
#
[manton] I honestly don't know. If a server has good error handling, then yes.
#
sknebel the only 2 ways I see it failing would be a) a server that returns a confirmation for input that's completely invalid to it, "eating" the post or b) a server that creates a junk entry for input it doesn't understand
#
Zegnat From discussions with implementers here, some had more trouble implementing form-encoded than JSON. Because they want to store mf2 json. He. But I also do not have any numbers on that, just anecdotal
#
Zegnat sknebel: I wonder if a JSON document could theoretically be a valid form-encoded string
#
[manton] For this specific discussion about alt tags, though... I can add mp-photo-alt with maybe a couple lines of code vs. completely changing how I send Micropub requests with fallbacks if JSON doesn't work, etc. That is a much more complicated solution.
#
sknebel fallback is easier for you as the client author. for all server authors it's another special case to support
#
sknebel if they want to offer the alt text feature
#
[manton] That's true. I'm not trying to solve everything right now, though... Just want to add this one feature that people have requested.
#
[manton] Preferring JSON is probably the way to go in the long run. And I do think there's a larger issue here with the complexity of supporting 2 flavors of an API.
#
[manton] Micropub is great because it's so approachable to show someone a POST form-encoded example. Easy to understand and implement quickly. But since there's not feature parity between form-encoded and JSON it gets kind of confusing.
#
sknebel sure. I don't want to be telling you "don't implement it this way", especially if it's mostly between your client and your server. but I think having JSON as the wider target makes sense, because it'd be a lot of extra stuff to bring FE up to parity
#
sknebel so the detection approach IMHO should be kept in mind
dougbeal|imac joined the channel
#
[manton] Thanks. Retrying a failed JSON POST just doesn't feel right to me. You could kind of say the same thing about OwnYourGram doing that instead of having a preference. I'd rather have a more formal convention for preferred format.
#
[manton] Sorry, I meant OwnYourSwarm, which sends more details in JSON than form-encoded.
[dougbeal] and [schmarty] joined the channel
#
[schmarty] [keithjgrant] I am late to the git lfs discussion but I will the result of my personal experience with it was noooooooooooooooo
#
[schmarty] I ended up replacing it with a micropuedoa endpoint that is essentially a dumb file store. plus my templates wrap those image section URLs to a self-hosted instance of (willnorriss’s?) imageproxy to handle resizing and orientation
[keithjgrant] joined the channel
#
[keithjgrant] Uh oh. Why not?
#
[schmarty] I was self hosting my git stuff at the time I set it up and it was fine, but I moved away from wanting to manage images all in my compile step
#
[keithjgrant] I host my images, but I serve them by proxy through Cloudinary for optimization/resizing. It's slick
#
[schmarty] git lfs hosting is not as much a “given” as other git hosting, and usually requires a separate http credential method than ssh keys
#
[schmarty] E.g. GitHub has pretty low limits on free LFS hosting. And each checkout requires extra setup to get at the actual media files
#
[schmarty] Eventually I decided it was worth treating as a totally separate kind of content and let the micropub media endpoint be the abstraction line
#
[schmarty] I am interested in playing with cloudinary or similar!
#
[keithjgrant] What's your micropub server?
#
[schmarty] My media endpoint is /Spano
#
[schmarty] It’s pretty much separate from my main micropub server. I run a custom server for my main site, a fork of skippy’s for another project
#
[keithjgrant] So do you post all micropub content to one endpoint, and it routes media to the correct place?
#
[schmarty] Most micropub clients will send media to the media endpoint directly, as long as the main micropub endpoint advertises that it exists
#
[keithjgrant] Interesting. Makes sense
#
[schmarty] But for those that don’t, my micropub endpoint will accept files and submit them to the media endpoint behind the scenes
#
[schmarty] For my static site, I treat those uploaded image URLs as “originals”, saving them in front matter attributes (photo, usually). My templates render those with imageproxy in front.
bashura_26 joined the channel
#
[schmarty] Mobile safari is genuinely frustrating me in trying to get at the img src, but this post is a good example if you want to check the source https://martymcgui.re/2018/07/25/190656/
#
Loqi [Marty McGuire] Photo for tonight’s HWC Baltimore https://martymcgui.re/imageproxy/960,fit,syruvQtGJqBToDfG0YV1k9u2gX3tQwgdwROK3vfkflGk=/https://media.martymcgui.re/3c/62/87/f8/825b936596e7baf7c24ff505c797720ff824677f7f49bcc3b0008738.jpg
#
[schmarty] Thank you, Loqi. You are a true friend.
#
[keithjgrant] Awesome thanks. I'm getting ready for a trip, but I'll have to circle back and check all this out
#
tantek___ what is git lfs
#
Loqi Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server https://indieweb.org/git_lfs
#
tantek___ [schmarty]: care to braindump the Issues / Criticism you ran into in there?
[dougbeal] joined the channel
#
@rubygems jekyll-webmention_io (3.2.0): This Gem includes a suite of tools for managing webmentions in Jekyll: * Tags *… https://rubygems.org/gems/jekyll-webmention_io (twitter.com/_/status/1041106085237678081)
d0tn0t16 joined the channel
#
GWG Indieauth supports pgp key logins, I believe
#
GWG I have a friend who has started encrypting his emails
#
GWG I have not done that in ages