#tantek.comedited /Instagram (+378) "merge Other Functionality into existing Features section, add a few, merge separate PESOS sections into one as well" (view diff)
#loqi.meedited /deviantART (+91) "petermolnar added "http://jon-rista.deviantart.com/journal/Very-Concerning-DeviantArt-com-License-221022234" to "See Also"" (view diff)
#petermolnarcweiske there is an assumption that .onion is shady, and for now; I'm already a linux sysadmin, I don't need more attention from the agencies :D
KartikPrabhu and KevinMarks joined the channel
#loqi.meedited /Ghost (+48) "aaronpk added "https://www.indiehackers.com/businesses/ghost" to "See Also"" (view diff)
#Zegnatbear, I am on 7.1, any idea if there was any overlap?
#ZegnatAsking before I go and read up on them myself.
#ZegnatAh, doesn’t seem I am affected either way. Still thanks for the heads up! :)
KevinMarks and cweiske joined the channel
#aaronpkalrighty... anyone who has written a Micropub client, I would appreciate if you filled out an implementation report!
#aaronpksince we need to move quickly on this, I decided to stick with a markdown file report like webmention, rather than waiting for me to complete the micropub.rocks test suite
#cweiskeaaronpk, I'm not able to complete a server report for commentpara.de because it only accepts likes+replies, while micropub.rocks wants to push "normal" posts
#aaronpkhm, I can make an .md version for that case
#martymcguire[m]how quickly do these implementation reports need to be up? i have a couple of in-progress micropub clients that need some cleanup, haha.
#martymcguire[m]i have a micropub client question that maybe other client implementors can help me understand
#martymcguire[m]one thing i have noticed about implementations like quill is a tendency to have their form submit to their own server (e.g. back to quill.p3k.io), which then submits the post to the micropub endpoint.
#martymcguire[m]in testing i tend to cut out that submit-to-a-proxy-endpoint step and just post straight to the micropub endpoint, though from a UI perspective it leaves the browser showing whatever comes back for the 201 Created (or similar) response.
#aaronpki'm trying to remember why I did that with Quill in the first place
#martymcguire[m]part of me wants to have a client that runs in the browser POST directly to the micropub endpoint (especially if it's already doing that for files with the micropub media endpoint)
#martymcguire[m]the big tripping hazard i think would be CORS.
#aaronpkoh, well for one, the micropub endpoint would need to have the CORS headers set up to allow that
#aaronpknot strictly required for this, but i thought it would be helpful information for the future
#martymcguire[m]my current thinking is that the browser-side of the app could check ?q=config and, if the request succeeds, plan to post directly from the browser. otherwise, fall back into a mode where it proxies through the server.
#aaronpkmartymcguire[m]: i suppose, tho that seems like a lot of work for the client, and what's the benefit?
#martymcguire[m]eliminates the two-legged POST through the app's server
#martymcguire[m]aaronpk: agreed. i would be very interested in micropub clients that are single-page applications which run directly in my browser without any behavior "hidden" in a server-side component.
#aaronpkmartymcguire[m]: yeah definitely, i think that's a good type of application for sure.
#aaronpki think there's room for both models though, one isn't necessarily better than the other
#martymcguire[m]so it sounds like i'd need at least one implementation report for a micropub server that sends CORS headers to allow posting via javascript from other domains
#martymcguire[m]and at least one for a micropub client that posts via javascript (requiring CORS headers)
#martymcguire[m]submitted another for screech (my janky WIP podcasting client). supports h-entry with u-audio, additional fields for metadata pulled from that audio such as artist, album, track title, duration, ...
#sknebelaaronpk: can you take a look at https://telegraph.p3k.io/webmention/11VoVXr4Exm9pUOaoH/details and help me figure out why it wants to use my webmention endpoint over HTTP? fetches of my homepage should redirect always to HTTPS, and only then include a (relative) path to the endpoint, which then also would be HTTPS
#aaronpk"This will test that your endpoint follows redirects on the target and resolves the relative URL relative to the resulting URL rather than the original URL."
#aaronpkyou do have an additional redirect in there, but I wouldn't think that would matter
#sknebelseems so, if I append the path I get there in the webmention header to https://webmention.rocks/test/23/page/ I get "method not allowed" (Because I test with the browser right now, and thus GET), if I append it to the redirect target I get "404 not found"
#sknebelstill, quite useful to just be able to look it up and say "ok, test 23 should cover that, why doesn't it", since there it is clearly documented what is supposed to happen (so it is easy to audit the test as well)