Request for XEP-0389 Support: Implementation Plan for GSoC Project

[assu-2000]

Is your feature request related to a problem? Please describe.
I am planning to implement XEP-0389 (Extensible In-Band Registration) as part of a Google Summer of Code project. This specification aims to improve upon the XEP-0077 by allowing multi-factor registration mechanisms (and account recovery). Incorporating XEP-0389 into ejabberd would enhance security and user experience during the registration process.

Describe the solution you'd like
I would like to integrate XEP-0389 into ejabberd, providing support for multi-factor registration and account recovery mechanisms. This involves updating the existing in-band registration process to align with the new standards defined in XEP-0389.

Describe alternatives you've considered
Continuing with XEP-0077 for in-band registration is an option, but it lacks the enhanced security and flexibility offered by XEP-0389.

Additional context

This implementation is part of a GSoC project as I specified earlier, and I am seeking feedback from the ejabberd development team to refine the approach and address potential challenges. Your insights will be invaluable in ensuring a successful integration of protocol into ejabberd.

[Neustradamus]

@kayikakeAssu: Have you progressed on it?

[assu-2000]

@Neustradamus , Still discussing about it with ejabberd team in D.M.

[assu-2000]

Would anyone review my work ?

https://pad.disroot.org/p/pravGSOC24

[asdofindia]

@kayikakeAssu - I believe the design on ejabberd section will have to be expanded for ejabberd team to give review.

In the limited context of Prav/Quicksy it is slightly easy to think, we can choose just one challenge type (maybe OOB challenge) and implement that. But for ejabberd project they might want to support all kinds of flows and if so also make it configurable for the sysadmins deploying ejabberd and perhaps even for module developers to extend this behaviour. I'm not sure. Perhaps a partial support of challenge types, supporting only an OOB flow with a configurable URL might be still a valuable addition.

[weiss]

@kayikakeAssu, for what it's worth, there's an earlier (three years old) attempt by Marc Schink you might want to have a look at:

https://gitlab.zapb.de/xmpp/p1-xmpp/-/tree/xep_389
https://gitlab.zapb.de/xmpp/ejabberd/-/tree/xep_389

[assu-2000]

@kayikakeAssu - I believe the design on ejabberd section will have to be expanded for ejabberd team to give review.

In the limited context of Prav/Quicksy it is slightly easy to think, we can choose just one challenge type (maybe OOB challenge) and implement that. But for ejabberd project they might want to support all kinds of flows and if so also make it configurable for the sysadmins deploying ejabberd and perhaps even for module developers to extend this behaviour. I'm not sure. Perhaps a partial support of challenge types, supporting only an OOB flow with a configurable URL might be still a valuable addition.

@asdofindia absolutely.
Involving ejabberd means we have to support all the flows and use cases of the XEP protocol. Whereas for Prav, we will adapt it to the challenges we support.
So, are we going to develop it for the benefit of the entire community? Or are we going to do so directly to our need, Prav in this case?

[assu-2000]

@kayikakeAssu, for what it's worth, there's an earlier (three years old) attempt by Marc Schink you might want to have a look at:

https://gitlab.zapb.de/xmpp/p1-xmpp/-/tree/xep_389 https://gitlab.zapb.de/xmpp/ejabberd/-/tree/xep_389

thank you @weiss . I am going through the code , was it successfull ?

[weiss]

was it successfull ?

It was created as the basis for invitations. The specs then went in a different direction than Marc suggested, and I think he wasn't too motivated (and/or lacked the time) to adapt/rewrite his code accordingly. Not sure about the state of the actual XEP-0389 code, sorry.

[assu-2000]

was it successfull ?

It was created as the basis for invitations. The specs then went in a different direction than Marc suggested, and I think he wasn't too motivated (and/or lacked the time) to adapt/rewrite his code accordingly. Not sure about the state of the actual XEP-0389 code, sorry.

No need to be sorry, your feedback has been so helpful @weiss :)

[pravi]

@asdofindia absolutely. Involving ejabberd means we have to support all the flows and use cases of the XEP protocol. Whereas for Prav, we will adapt it to the challenges we support. So, are we going to develop it for the benefit of the entire community? Or are we going to do so directly to our need, Prav in this case?

We can start with the easiest option that can work for Prav and consider more options later.