jacky, ShinyCyril, darkkirb, gRegor, [James_Van_Dyne], sknebel, strugee, [tw2113_Slack_], [chrisaldrich], angelo, sebbu, Kaja, wiki[m] and Vikasheher[m] joined the channel
#jamietanna1For media-endpoint queries, are they expected to be only to the separate media-endpoint or can they also be to the micropub endpoint if no media-endpoint is advertised?
mro and neceve joined the channel
#aaronpkI would not assume the micropub endpoint would also act as a media endpoint
tetov-irc, gRegor, Saklad51, shindakun1, jamietanna, jacky and jamietanna1 joined the channel
#jamietanna1sorry so I'm thinking "if q=config shows media-endpoint, use that for queries, otherwise use the plain micropub for i.e. q=last"
#jamietanna1or am I conflating media-endpoint with "place that files are uploaded"
#jamietanna1> To upload files, the client MUST check for the presence of a Media Endpoint. If there is no Media Endpoint, the client can assume that the Micropub endpoint accepts files directly, and can send the request to it directly.
#GWGShould unauthenticated access to q=config be allowed to get the media endpoint?
#jamietanna1I would say yes because I don't see why q=config should require authentication, but I know lots of folks do it
#jamietanna1Media endpoint still requires authentication, so aside from a brute force attack, what would we be protecting?
#[schmarty]jamietanna: that language is for clients that need to upload files. if there's no Media Endpoint, file data can be sent to the Micropub endpoint in a multipart POST
#[schmarty]it does not mean that the client should expect the Micropub endpoint to implement any features of the Media Endpoint extension to the spec.
jacky joined the channel
#[schmarty](if a Micropub endpoint _does_ support Media Endpoint extensions, it can list itself in q=config)
#[manton]I allow un-auth q=config, but just don’t return anything that is user-specific. So that basically just means show the media-endpoint URL.
#GWG[manton]: That is the basic idea I'm proposing, along with possibly thinking of some other parameters that should be retrievable that way
#[manton]In practice I don’t think this will come up very often. Most likely clients are already going to have auth credentials before they hit anything Micropub.
#jamietanna1I guess the question is what sensitive info could really be in there? https://www-api.jvt.me/micropub?q=config is unprotected and I don't think there'd be anything of issue, nor could I see with others?
#jackyfor me, it could be things like my destinations and syndication targets
#[snarfed]what's the use case for un-authenticated access to q=config?
#GWGMicropub Media Endpoints are often implemented as separate services from a site's "main" Micropub endpoint, it may be useful to allow Micropub clients to discover the media endpoint.
#aaronpki would not want to share the list of my syndication targets publicly
#GWGaaronpk: I agree. I was thinking of [manton]'s implementation example, where you can get the media endpoint URL without authenticaiton
#aaronpkright but in practice a micropub client isn't going to fetch the config until after the user has logged in anyway
#GWGIn this case, it seemed to be based on jamietanna1's use case
#jackyI don't think jamietanna1 listed a use-case though
#jamietanna1I've found that it can be useful for a lot of unauthenticated requests so i.e. I can q=source a post's MF2 when I'm not logged in (i.e. using a browser)
jacky joined the channel
#jamietanna1syndication targets make sense - is that because the URLs themselves are sensitive and allow others to post to it, or just because it'll share information of where you _may_ syndicate to?
#[manton]I wouldn’t want q=source to be public either because it could contain drafts or private posts. A crawler is probably better served by parsing public h-feeds, RSS, or JSON Feeds.
jacky joined the channel
#[manton]Put another way: I don’t think Micropub needs to be a replacement for feeds.
#[schmarty]it also seems like q=config, source, etc might contain different stuff per authenticated user (for multi-user/multi-site endpoints) or per client (e.g. clients might not be allowed to see all syndication targets or sources of posts they didn't make, etc)
#[schmarty]in terms of trying to achieve some sort of endpoint <=> client handshaking over capabilities, it seems risky to try and overload q=config to do that. the consuming case needs a lot of speccing out lol
gRegor joined the channel
#GWGI wonder if advertising Micropub in the IndieAuth metadata file is a bad idea.
#aaronpkmicropub endpoint advertises the indieauth endpoint
#[manton]To get the IndieAuth endpoint, you have to parse HTML that also has the Micropub endpoint. Might as well get them both at the same time! I’m not sure what problem this discussion is trying to solve. 🙂
#[schmarty]my main push for separate rel was because a micropub media endpoint can be a separate service from a micropub endpoint, so requiring the micropub endpoint to exist and to "know about" the media endpoint feels like unnecessary coupling.
#[schmarty]a separate rel *for the micropub media endpoint
#jackyand it allows me to have a working implementation :)
#jackymainly b/c my framework doesn't have multipart support lol
jacky joined the channel
#[tantek]cont'd from #indieweb I've been relatively happy with Dreamhost and my minimal PHP setup there. I think one thing broke once when they upgraded my PHP for me but was able to fix it relatively quickly.
#[fluffy]yeah, and usually if something breaks in a PHP upgrade it’s because it was using code which had some serious security problems.
#jamietanna1ah yeah I'd not thought about client-specific syndication too, mine is generic for all clients
#[tantek]yeah in this case it was syntax fidgetiness
#jamietanna1jacky sorry the GitHub example was more "when sharing on GitHub for micropub-extensions" or giving folks an example of what my server supports, which isn't a regular occurrence
#gRegorMy sock puppets stay in my room, don't have online presence
#[tantek]was there some actual reason given for why people started saying "social graph" instead of "social network"? or was that just Zuckerberg mimickry?
#[KevinMarks]Ah, interesting. It was definitely discussed before then
#[tantek]I don't remember it being discussed before then. I do remember Zuck speaking to it as if it was a big new thing at F8, and I also remember Brad posting about it basically in response to that
#[tantek]before that, everyone said "social network", like YASNS etc.
#[KevinMarks]I think foaf people called it a graph, but I'd have to chase citations
#[tantek][KevinMarks] no, there is no occurence of "social graph" in that Wikipedia article "Social network analysis". Yes the word "graph" has been used in discussions of "social networks", however the phrase "social graph" doesn't have prior citaitons
#[tantek]jacky, which WebID folks, classic RDF WebID, or new shiny Google WebID?
#[tantek]tbh I have no idea which the credweb folks would be into. there's some SemWebbers in there, and there's some Googlers in there, and maybe even an overlap of 1-2.
#[tantek]XFN Graph is a good find [KevinMarks], from 2005 apparently!
#LoqiUsing rel=me on a hyperlink indicates that its destination represents the same person or entity as the current page, which is a key building-block of web-sign-in and IndieAuth https://indieweb.org/rel-me
#[tantek]jacky, yeah, we kinda hit a local maxima back in the ~2008-2009 era with "social network portability", and the conversations were unfortunately rebranded and hijacked to be focused on *the* social graph, as if we had to redo everything all over again
#[tantek]instead it resulted in open effort stagnating (nothing open benefited from the phrase "social graph"), and dominant silos gaining more and more default acceptance as the home for people's social networks (primarily FB and Twitter)
#[tantek]and yes, the list of sites and services is horribly out of date, and probably more useful today to help document more /site-deaths
jacky_, jacky, [aciccarello], tetov-irc and sp1ff joined the channel