jcI still want to create a pubsub module for converse.js that can be used to add comments to a website
jcJust don't have the time at all π’
alacerhas joined
alacerhas left
arnaudjhas left
arnaudjhas joined
alacerhas joined
LNJhas joined
nycohas left
nycohas joined
Guushas left
Guushas joined
Guushas left
ralphmhas joined
arnaudjhas left
arnaudjhas joined
alacerhas left
alacerhas joined
ralphmhas left
Guushas joined
ralphmhas joined
ralphmhas left
ralphmhas joined
nycohas left
Guushas left
Guushas joined
Guushas left
nycohas joined
arnaudjhas left
arnaudjhas joined
arnaudjhas left
arnaudjhas joined
arnaudjhas left
arnaudjhas joined
Guushas joined
LNJhas left
alacerhas left
alacerhas joined
pep.jc, yeah helping on that pubsub thing is also in my todo somewhere. That would force people to get XMPP accounts, so we also need to work on the onboarding story I guess
jcConverse already supports OAuth login, so that could be extended upon to make it easier for people to comment
pep.Hmm, would that application be attached to the blogger's XMPP server or sth?
jcCould provide a hosted service and if people want to set it up themselves they can as well
pep.How does the OAuth thing work? You can limit authorized providers right?
jcyes
pep.Ok. That would still mean duplication (of accounts) I guess, if some people use the hosted service, and some others use self-hosted services. People using oauth would create accounts on all of these instances
pep.*confusion ensues*
jcNot if federation is enabled
pep.How do I know as a self-hoster what is the identity authority for the guy using oauth?
jcWhy do you care?
jcIf you're federating you don't have anything like that for other XMPP servers
pep.I don't understand
jcYou need an XMPP server which supports OAuth login, so ultimately it is still an XMPP account
pep.Sure
jcAnd if you federate, then there's not much difference between an OAuth account or a normal account
pep.There is
pep.Well
pep.Ok we're not aligned here
jcAh, you mean the client doesn't allow all authority providers
jcwell, then that's the way it is
pep.No I'm saying,
Guushas left
Guushas joined
pep.HosterA, HosterB, Github, userA. userA first creates an account at HosterA using their Github identity,
pep.They now have access to AccountsA
pep.userA goes to HosterB, do they create an account? What if they don't understand anything at XMPP and they just try to login using OAuth again, creating AccountB on HosterB
pep.How does HosterB knows in the first place that AccountA is even a thing
jcDepends on how HosterB is set up
jcBut yes, it could happen
pep.That's why I was talking about account duplication, federation or not
pep.Or you'd create another big node of users, that hosted service
jcComments aren't federated currently anyway, so either you have a centralized account on Disquss, or on each site that uses its own comments you have a new account
pep.If you look at things on the web, that's true
pep.If you look at things done in XMPP currently, that's less true
jcYes, I was thinking of having a de facto XMPP server handling OAuth accounts, and people could delegate to that
jcAnd if they really want to self-host OAuth accounts, then they can, then there's account duplication
pep.Well the best would be for github to have their own account
pep.Well the best would be for github to have their own xmpp server
pep.Best, yes and no
jcThe way I set up OAuth is for each OAuth provider to have it's own VirtualHost on the Prosody server
pep.That would be yet another huge hub of users
pep.Rigt
jcAnd you could configure converse.js to use those hosts by default
pep.Rigth
Guushas left
pep.That doesn't really solve my problem, but then I don't know if much can be done for that either
jcwhat is your problem?
SouLHaving all users at the same place?
alacerhas left
pep.SouL, that's a problem that arises while trying to solve my problem :/
pep.My first issue is,
pep.I would like userA to be able to reuse the first account they created on HosterA, while not especially be XMPP-savvy
pep.I would like userA to be able to reuse the first account they created on HosterA, while not especially being XMPP-savvy
jcThat's fine, as long as the client is using the default configuration
jcThen it'll route Github logins to the right XMPP sever
pep.And I don't want to limit userA to the one big hoster out there
jcWell, that's really the issue π In that case, they shouldn't use OAuth, and 99.99% of the people who use OAuth wouldn't care about it IMO
pep.True..
jcBy using OAuth they're indicating that they don't care
pep.But then,
pep.Do "we" the community "design" somebody who's going to play the github identity provider? :/
pep.Because that's essentially what you're saying no?
jcI'm not thinking of doing this for the XSF
pep.sure, XSF or not
jcThis is a personal project, and maybe I can charge for hosting
jcAnd I'd be happy to work with people on it
jcSince I'm overloaded as it it
jcSince I'm overloaded as it is
pep.Yeah that's also something I'd like to work on tbh
SouLIt is something we need, so..
jcI'm looking for sustainable ways to work on Converse.js, and that means generating income
jcNot just for me, but for everyone involved of course
pep.One other thing, you say "as long as the client is using the default configuration, then it'll router Github logins to the right XMPP server", that means you expect self-hoster to also route github logins to that one big hub?
jcpep. Well, once you have time, let me know and we can discuss how to go about it
vaulorhas joined
jcpep. Unless they configure the client to not do it
jcIt's the default
jcMost people want to allow people to log in with OAuth, because most bloggers want to lower the barrier to entry for spam
jcMost people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for spam
jcMost people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for comments (haha
jcMost people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for comments (haha)
jcFreudian slip
pep.:D
jcI was thinking about spam
pep.Ok, so really the identity provider I'm trusting is BigHoster, not Github
jcYou're trusting BigHoster, but I'm not sure it's correct to call it the identity provider
jcGithub is the identity provider
pep.In the case of XMPP it isn't. as self-hoster if I have them create an account on bighoster, I'm trusting bighoster :P
pep.I don't even have to know about github
jcYou're gonna have an order of magnitude more spam from normal XMPP accounts, than from OAuth/BigHoster accounts π
jctrue
pep.Yeah it's not a case of "I'm worried about spam"
jcwhat are you worried about?
pep.Just trying to understand and make things clear
pep.Trust is always an issue :P
jcAny other XMPP server you're federating you have to trust
jcBigHoster is just another one
jcAny other XMPP server you're federating with you have to trust
pep.True
pep.btw, unrelated, these 4 messages above were supposed to be LMC?
jcYes
pep.I only got the first one corrected
pep.20:40:59 jc1> Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for spam
20:41:07 jc> Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for comments (haha
20:41:09 jc> Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for comments (haha)
jcBug in poezio π
pep.Impossible!
jcOh, Converse.js allows editing earlier messages than the last
jcCould be that
Link Mauvejc, poezio too.
pep.nah, poezio should also
Link Mauvejc, my guess is that you corrected the first id three times, while poezio replaces the entire message with the correction as per the XEP, including the id.
jcLink Mauve: that sounds right
jcSo Converse is not spec-compliant?
pep.gets his pointy fingers to point at converse
pep.:P
Vaulorhas joined
alacerhas joined
jcI don't actually see that the XEP says this explicitly
jcLink Mauve: Can you quote where in the XEP this is said?
Link MauveHmm, βIt is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.β
Link MauveThat may mean only payloads, and not attributes of the outer message.
Link MauveBut then, why?
pep.why what? What this SHOULD?
pep.I guess it's mostly for consistency?
jcWell well well...
jcπ
SouLgrabs the popcorn
jcShould I make a bug report for Poezio? π
SouLBooom
SouLHaha
SouLis just joking :D
Link Mauvejc, or a fix to the XEP to specify that the stanza replaces the old one, period?
jcI'm not sure that this is better...
pep.err, do you really want to do that?
Link Mauvepep., thatβs what we do yes.
jcThey all replace the original stanza
jcI can see arguments for both ways of doing things
Link MauveIt avoids having to go back in the history tree up to the root stanza and modify it again.
pep.What about all other payloads in the stanza? That means you can remove anything outside of <body/>?
alacerhas left
Neustradamushas left
pep.(well it's already used for xhtml-im etc., I guess, and also omemo, pgp, and whatnots)
Neustradamushas joined
pep.Or wait no, not OMEMO
pep.Or at least it shouldn't, privacy [blah blah]
Link Mauvepep., yes, all of the payloads, and here I argue that it should also replace the attributes of the stanza.
pep.That's not generally something I'm really fond of, mutability :x
pep.Also, "hijack commteam@ for your new pet bug 101", available today in your syllabus
jcNothing we've talked about this whole conversation is relevant to this MUC
pep.True
pep."How to put XMPP MUCs to good use"
pep.So.. open a bug on poezio, and converse, with a "This needs to be resolved by trial by combat on standards@"?
jcWell, Converse is spec-compliant as it's currently written