I still want to create a pubsub module for converse.js that can be used to add comments to a website
jc
Just 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
jc
Converse 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?
jc
Could 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?
jc
yes
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*
jc
Not if federation is enabled
pep.
How do I know as a self-hoster what is the identity authority for the guy using oauth?
jc
Why do you care?
jc
If you're federating you don't have anything like that for other XMPP servers
pep.
I don't understand
jc
You need an XMPP server which supports OAuth login, so ultimately it is still an XMPP account
pep.
Sure
jc
And 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
jc
Ah, you mean the client doesn't allow all authority providers
jc
well, 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
jc
Depends on how HosterB is set up
jc
But 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
jc
Comments 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
jc
Yes, I was thinking of having a de facto XMPP server handling OAuth accounts, and people could delegate to that
jc
And 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
jc
The way I set up OAuth is for each OAuth provider to have it's own VirtualHost on the Prosody server
That doesn't really solve my problem, but then I don't know if much can be done for that either
jc
what is your problem?
SouL
Having 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 ✏
jc
That's fine, as long as the client is using the default configuration
jc
Then 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
jc
Well, 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..
jc
By 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?
jc
I'm not thinking of doing this for the XSF
pep.
sure, XSF or not
jc
This is a personal project, and maybe I can charge for hosting
jc
And I'd be happy to work with people on it
jc
Since I'm overloaded as it it
jc
Since I'm overloaded as it is
pep.
Yeah that's also something I'd like to work on tbh
SouL
It is something we need, so..
jc
I'm looking for sustainable ways to work on Converse.js, and that means generating income
jc
Not 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?
jc
pep. Well, once you have time, let me know and we can discuss how to go about it
vaulorhas joined
jc
pep. Unless they configure the client to not do it
jc
It's the default
jc
Most people want to allow people to log in with OAuth, because most bloggers want to lower the barrier to entry for spam
jc
Most people want to allow commenters to log in with OAuth, because most bloggers want to lower the barrier to entry for spam
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
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)
jc
Freudian slip
pep.
:D
jc
I was thinking about spam
pep.
Ok, so really the identity provider I'm trusting is BigHoster, not Github
jc
You're trusting BigHoster, but I'm not sure it's correct to call it the identity provider
jc
Github 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
jc
You're gonna have an order of magnitude more spam from normal XMPP accounts, than from OAuth/BigHoster accounts π
jc
true
pep.
Yeah it's not a case of "I'm worried about spam"
jc
what are you worried about?
pep.
Just trying to understand and make things clear
pep.
Trust is always an issue :P
jc
Any other XMPP server you're federating you have to trust
jc
BigHoster is just another one
jc
Any 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?
jc
Yes
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)
jc
Bug in poezio π
pep.
Impossible!
jc
Oh, Converse.js allows editing earlier messages than the last
jc
Could be that
Link Mauve
jc, poezio too.
pep.
nah, poezio should also
Link Mauve
jc, 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.
jc
Link Mauve: that sounds right
jc
So Converse is not spec-compliant?
pep.gets his pointy fingers to point at converse
pep.
:P
Vaulorhas joined
alacerhas joined
jc
I don't actually see that the XEP says this explicitly
jc
Link Mauve: Can you quote where in the XEP this is said?
Link Mauve
Hmm, β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 Mauve
That may mean only payloads, and not attributes of the outer message.
Link Mauve
But then, why?
pep.
why what? What this SHOULD?
pep.
I guess it's mostly for consistency?
jc
Well well well...
jc
π
SouLgrabs the popcorn
jc
Should I make a bug report for Poezio? π
SouL
Booom
SouL
Haha
SouLis just joking :D
Link Mauve
jc, or a fix to the XEP to specify that the stanza replaces the old one, period?
jc
I'm not sure that this is better...
pep.
err, do you really want to do that?
Link Mauve
pep., thatβs what we do yes.
jc
They all replace the original stanza
jc
I can see arguments for both ways of doing things
Link Mauve
It 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 Mauve
pep., 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
jc
Nothing 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@"?
jc
Well, Converse is spec-compliant as it's currently written