#social 2018-06-04

2018-06-04 UTC
#
dansup I thought I could finish AP support this weekend, how naive. Responding to all the github issues/PRs has taken up a lot of time
#
dansup Registration is open for the next 10 mins, https://pixelfed.social/register
Guest84, timbl, xmpp-social, jankusanagi_, puckipedia and JanKusanagi joined the channel
#
cwebber2 I suppose we should mock out what all the activitypub workflow would be for federated PRs/issues
cjslep, puckipedia, timbl, cwebber2 and JonasFranzDEV joined the channel
#
JonasFranzDEV cwebber2: Are you the ActivityPub co-editor who wrotes the comment about ActivityPub at Gitea?
#
JonasFranzDEV slaps cwebber2 around a bit with a large fishbot
#
cwebber2 JonasFranzDEV: yow! yep I am
#
cwebber2 welcome to #social :)
#
JonasFranzDEV cwebber2: Do you think that it is a good idea to use the ActivityPub standard for creating a federation support for Gitea including: Joining organizations/teams on other Gitea instances, creating PRs at other gitea instances, replying to comments on issues on other gitea instances. How is authentication handled?
#
nightpool mayyyybe?
#
nightpool we've been talking about federation for gitlab and i think the #1 use-case to be solved is authentication and that's not something that's explicitly within AP's scope
#
cwebber2 JonasFranzDEV: so.... I think it's a great idea, but I think the only way to do it sanely might be to use ocap-ld
#
cwebber2 https://w3c-ccg.github.io/ocap-ld/
#
cwebber2 otherwise you're going to have to federate ACLs and it's going to be a nightmare
#
cwebber2 unfortunately ocap-ld is still in flux... but, it may be stable enough to start picking it up for something like this, if you're willing to work with us
#
nightpool was actually just about to ask in here if anyone had any experience with oauth for federated usecases and whether they thought it was a good match
#
cwebber2 so, ocap-ld is the right way to do it IMO (though I'm biased, but this is one of the reasons I stared working on it). If I give you access to something
#
cwebber2 I hand you a capability with one of your keys being bestowed acces
#
cwebber2 s
#
cwebber2 and then you can invoke it *as part of* your activitystreams activity
#
aaronpk nightpool: IndieAuth is essentially federated OAuth
#
cwebber2 so for example
#
aaronpk https://www.w3.org/TR/indieauth/
#
cwebber2 {"type": "MergePR", "proof": {"proofPurpose": "invokeCapability", "capability": <capability-you-got-here>, ...sig stuff...}
#
cwebber2 ?
#
cwebber2 ?
#
cwebber2 er
#
cwebber2 }
#
cwebber2 yarg
#
nightpool cwebber2: not sure I see the compelling use-case for this vs. just handling ACLs locally
#
nightpool because 1 server always owns a single repo, right?
#
JonasFranzDEV Do I get this right? ocap-ld is an extension for json-ld handling access control? And yes, 1 server per repo.
#
nightpool aaronpk: would you recommend it for the "I dont want to create accounts on everyone's bespoke gitlab/gitea servers" usecase?
#
aaronpk absolutely yes
#
cwebber2 nightpool: while that's true, ACLs create a lot of problems :\
#
aaronpk https://aaronparecki.com/2018/06/04/6/gitea-indieauth
#
Loqi [Aaron Parecki] What we really need is federated authentication, but that doesn't exist yet. This sounds like a great use case for IndieAuth. w3.org/TR/indieauth IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth soluti...
#
aaronpk I commented on that github issue from my website :)
#
cwebber2 oauth 2.0 bearer tokens are still better than ACLs because they won't require synchronization
#
nightpool aaronpk: :o github-wise, how does that work?
#
aaronpk for github there's a proxy that takes my post and sends it to the github API. but ideally gogs/gitea/gitlab would see the webmention from my site to the issue and parse it out from there
#
nightpool ahhh right it's bridged
#
nightpool looks very fancy imo
#
nightpool what happens if you reply to that post without having auth'd a github account with the bridge?
#
aaronpk it doesn't work, it needs github auth
#
aaronpk yeah it's bridged cause the odds of github adopting an open standard for this are low. but we can change that with the open source ones!
#
aaronpk but yeah the OAuth question, IndieAuth is basically a way to do OAuth that doesn't require registering apps on every instance using it, since it uses DNS as a replacement for client registration
#
aaronpk everyone's gogs/gitea/gitlab profile URL would be the user identity
#
nightpool hmm
#
aaronpk it'd be a good step in the right direction before full issue federation
#
aaronpk at least that way I could log in to other instances without making an account
#
JonasFranzDEV aaronpk: That's a great idea, could you please propose that at https://github.com/go-gitea/gitea/issues/27 since we haven't integrated an oauth provider either.
#
Loqi [tboerger] #27 Integrate an OAuth2 provider
#
JonasFranzDEV aaronpk: Am I right that IndieWeb services also support standard oauth things?
#
aaronpk yes, most Micropub apps use IndieAuth to log in
#
nightpool "(requiring manual steps, like OpenID) to make it into mainstream.
#
nightpool this doesn't eliminate the manual step of providing your profile URL, right?
#
nightpool Unless i'm misunderstanding, how does it improve upon OpenID in that sense?
#
aaronpk correct, you'd need something additional to fix that. a browser extension or a centralized service could solve that.
#
aaronpk but that's kind of a fundamental problem with federated identity in general. how do you tell the site who you are without telling it who you are
#
aaronpk facebook/google/etc get around it by being centralized services, then getting apps to include all the login buttons turning them into NASCAR interfaces
#
nightpool well i mean there's also web protocol handlers
#
aaronpk yeah we've had some luck with that too
#
nightpool the UX around those is kind of hard to nail though
#
aaronpk yeah, really needs browser support for it to be easy
#
aaronpk but the IndieAuth spec details redirect handling to make it easier for people to enter their URLs. for example I can enter my short URL "aaronpk.com" in a login screen and it'll eventually end up expanded to "https://aaronparecki.com/"
#
nightpool i dunno, a slightly difficult flow aided by a browser extension is not the worst thing in the world.
#
nightpool most people don't own domains
#
aaronpk yeah it doesn't require that you own a domain
#
csarven WebID+TLS+Certs.
#
aaronpk trolol
#
nightpool sure, but it does require that you enter cybre.space/@nightpool everywhere.
#
aaronpk yeah, but it'd be a very small browser extension to autofill that
#
nightpool yeah but what do you even put in there
#
aaronpk what do you mean?
#
nightpool how do users know if they even HAVE a indieauth capable account?
#
csarven aaronpk Excuse me?
#
aaronpk if gitea is an indieauth server, and the user has a gitea instance, then they have an indieauth account
#
aaronpk csarven: oh are you serious? I legitimately thought you were joking
#
nightpool like, if I have a mastodon account and mastodon implements indieauth, and I go to someone's repo and try to comment, how do I know I can use my mastodon profile url?
#
aaronpk nightpool: i'd expect that initially people would be using their own gitea/gogs/gitlab accounts as their profile URLs
#
csarven Interesting you say that because I'm sincerely not sure what you understand of it.
#
aaronpk csarven: last thing I heard was browsers were dropping support for client certs, and I thought all the WebID stuff had died off, given that webid.info doesn't seem to be responding anymore for example
#
nightpool what i'm saying is that it's pretty easy to say "Use your gitea profile url here" on a gitea server, but it's harder to say "use your gitlab/mastodon/gogs/etc"
#
aaronpk nightpool: we call it "web sign-in". and I agree it's a trick to let people know that they might already have a profile URL that supports it
#
nightpool needs a logo :P
#
aaronpk hehe probably
#
nightpool although even that didn't help openid
#
aaronpk RIP OpenID
#
aaronpk at least this time around the protocol is way easier to implement
#
csarven aaronpk I now understand what you understand of it.
#
nightpool hmm. i'm pretty sold though. is there a good test website for authenticating against? would enjoy implementing this in mastodon
JonasFranz joined the channel
#
aaronpk nightpool: no formal test suite, but there are plenty of things you can log in to to try it. https://indielogin.com is the latest one I'm working on. (it technically supports more than the IndieAuth spec but you can ignore the rest for now)
JanKusanagi joined the channel
#
aaronpk oh and https://quill.p3k.io is a micropub app that has good debugging during the login flow. it does expect to eventually find a micropub endpoint for you but you could fake that if you just wanted to test login
JonasFranz, cwebber2 and tantek joined the channel
#
tantek This tweet totally reminds me of our "must be testable in the test suite" requirement for features in our SocialWG specs: https://twitter.com/shadow/status/1001686735443628033
#
Loqi [@shadow] @alicegoldfuss If you can’t reproducibly test a feature you can’t promise support for it.
#
Loqi tantek: sandro left you a message 1 week, 4 days ago: yes the Fact Checking discussion is in a W3C CG, so it's public to anyone who can join a CG (nearly anyone), and scribed. https://credweb.org
#
tantek !tell sandro great - looking forward to when the July f2f dates are known / posted on credweb.org
#
Loqi Ok, I'll tell them that when I see them next
timbl joined the channel
#
ajordan tantek++
#
Loqi tantek has 78 karma in this channel (438 overall)
#
dansup trying to relicense under AGPL, just need 1 more contributor to agree. https://github.com/dansup/pixelfed/issues/143
#
Loqi [oct2pus] #143 Relicence Pixelfed as AGPLv3
#
aaronpk hehe always add a contributing.md that makes people agree to let you relicense
#
tantek ajordan do you have any projects (including feature for your own site) you'd like to complete before IWS? I.e. add yourself to https://indieweb.org/2018/Guest_Book (see my entry for how I linked to what I'm trying to get done before IWS)