Great Invitations - #4750
Conversation
|
Hi @sstrigler, currently this PR looks like a POC. I think that it would need to be changed significantly if we were to incorporate this into MongooseIM:
Overall, this is an interesting idea, and it might be useful in some use cases, but currently this is low priority for us, so we can't promise that a MIM developer would look into this soon. Please let us know if this becomes more mature and ready for review. |
|
Hi, @chrzaszcz, thanks for taking the time and looking into this PR already. Adding tests (or rather porting) would have been my next step. This situation is quite unfortunate since this PR is not meant as a PoC. We had a phone call about this feature about a year ago, not sure if you were part of it (I have a bad memory when it comes down to names, sorry about that). It seems there was some miscommunication then. The basic idea here was to take the work I've done for ejabberd and port it to MongooseIM with as little extra costs as possible (low hanging fruit). Their (NLnet's) rationale behind it is to make maximum use of their investments. From their point of view it's all just Erlang after all. Probably my fault not communicating this aspect clearly enough. I totally get your point and what you want to see for your project, to me it makes perfect sense. But if I had to change the coding style (whatever it implies concretely) would mean that I'd end up with two different (albeit sort of similar) implementations that someone would have to maintain, and that obviously wouldn't just be you. Not to speak of the costs that NLnet probably isn't willing to cover. In addition to the dynamic domain feature (undeniably a core selling point of your platform). So what I'll do next now is to circle back to NLnet and discuss the situation. It's a bit unfortunate since probably I won't see any money for the work I've done already, while - to be perfectly honest - if there's so much more to it, personally I don't feel inclined to pursue this (or any other PR) any further. |
|
@sstrigler I only wanted to say that we cannot accept the PR as it is (without tests). If you could cover the whole functionality with tests in |
|
@chrzaszcz ok, this sounded more dramatic to me at first. But still, what about dynamic domains then? Btw, there's no rush to it of course. PS: There's still more missing from the PR (it's still a draft after all), besides tests, there'd also be an integrated landing page that guides users on how to actually install a client and get going. PPS: For ejabberd I'm planning on adding another feature on top of it all that would allow to request an invite by giving an email or phone number where an invite link would be sent to, validating the datum in the process. For ejabberd there'd be another option to manually approve incoming requests before invites they are being sent out. Since MIM is missing an admin backend, not sure how to integrate this. |
|
Oh yes, dynamic domains - this is a must. Overall, converting the code to support them usually brings the code quality up a lot, so yes - it would need to be done before accepting this PR as well. What I wanted to say initially was that we do not have the manpower to invest in this now. "MIM is missing an admin backend" - MongooseIM has the Admin GraphQL API, and one for Domain Admin as well. I don't know how it would be missing an admin backend... |
|
I meant a web-admin, ie a GUI that goes beyond the bare data. I suppose in that case, having the data accessible via REST/GraphQL would be enough, since whatever integration you have they'd be responsible to fit things to their needs anyway - one way or the other. |
|
Good news, NLnet will be paying to support dynamic domains. 🥳 |
A port of ejabberd's new mod_invites, an implementation of "Great Invitations" as found in prosody, implementing XEPs 0401, 0379 and 0445.
This work is being funded through NLnet and the NGI0 Commons Fund: https://nlnet.nl/project/ejabberd-invites/
To complete this feature set an implementation of roster pre-approval as described at https://www.rfc-editor.org/info/rfc6121/#section-3.4 would be advised but is out of scope for this PR and would require further funding. (See #783)
There's no support for 'dynamic domains' (i.e. not using
HostType?) at the moment. I figured I lack thorough understanding of this matter and as such it would require further funding since it goes beyond a simple port of the original.