Linking phone number similar to the Quicksy app

[pravi]

Description of my issue or feature request:

https://quicksy.im is a hack to provide same level of on boarding experience as centralized services like WhatsApp or Signal. Since it is a modified version of conversations android app, it supports only Android.

It'd be good if Monal IM offers an option to sign up to Quicksy. Either directly or as a separate rebranded app.

Current option of linking phone number and XMPP id is confusing for people.

The Monal version and system version I use:

Additional information like screenshots:

https://github.com/tigase/siskin-im/issues/90

---

[x] I have cross-check this overview https://github.com/monal-im/Monal/issues/322 as well as filtered for related labels https://github.com/monal-im/Monal/issues/labels

[tmolitor-stud-tu]

We already had a conference with the Quicksy developer about this and are aiming for a rebranded version, but this will be something based on Monal 5.1 or even 5.2 (e.g. 2 or 3 releases in the future).

[licaon-kter]

What's the baseline feature set missing, besides group omemo?

[tmolitor-stud-tu]

support for groups and channels in general...and omemo for groups of course.

[tmolitor-stud-tu]

I'll close this, the rebranding is already in the pipeline and this has nothing to do with monal in general.

[pravi]

@tmolitor-stud-tu is there any progress on this rebranding?

[pravi]

@tmolitor-stud-tu @Echolon if we raise some funds via a crowd funding campaign, can this be prioritized? Or alternatively if someone implement it independently, would this be accepted in Monal (may be as a build time configuration option to choose which flavor to build like how conversations does it currently). We'd like to have iOS client for https://prav.app which is based on Quicksy.im and basing it on Monal would be nice.

[tmolitor-stud-tu]

We've already talked to Daniel and agreed that we want to create a Monal-based Quicksy once Monal is in feature parity with Conversations (namely MUC management and A/V calls).

We don't have the bandwidth to work on this right now, because we are already busy implementing A/V calls and MUC management. But we are always happy to take pull requests: if someone external wants to implement this, go ahead :)

[pravi]

@tmolitor-stud-tu what do you think about XEP-0389? Would it better to have a standardized way to have phone number verification? This would mean we will have to modify the server side too at prav, but if more clients can work with it, that may be worth the effort.

[tmolitor-stud-tu]

Standardized ways are always better than homegrown niche solutions, so feel free to implement XEP-0389 and create a PR :)

[poVoq]

I understood at the congress that this is now work in progress? Maybe time to reopen this issue 😊

[tmolitor-stud-tu]

@poVoq yes

[pravi]

@tmolitor-stud-tu can you also build a rebranded Prav App for us? This would be just a change in the app name and server address (quicksy.im -> prav.app, later we plan to add custom username support as well). We can also contribute towards apple developer account expenses (if we have to get another account, that will be 99 USD per year, we'd prefer to pay you than Apple). We'd also like to maintain this directly in Monal repo if possible (building different apps based on some build configuration variables - like how Quicksy and conversations are built for android from same repo).

[tmolitor-stud-tu]

@pravi No, currently there are no plans to maintain any other rebranded versions besides Quicksy.

[gi-yt]

@poVoq yes

Is there any branch where this is being worked on and/or a timeframe as to when it will be created?

I would like to contribute to the same.

[pravi]

@tmolitor-stud-tu can you please share the current status of this work? @gi-yt wants to work on this for Prav App, but we'd like to avoid duplicating work you have done already. We have raised some funds for this work https://opencollective.com/prav-ios

[tmolitor-stud-tu]

@pravi We did not yet start implementing the quicksy parts.

But on that occasion: I just saw the GSOC proposal "Implementation of XEP-0388 in the Prav Server for secure signup on prav.app using any XMPP client."

That's complete nonsense. XEP-0388 isn't for registering users, but for authenticating existing users. You should use XEP-0389: Extensible In-Band Registration for this.

The XEP even mentions your usecase:

As a server operator I want to prevent SPIM using a proof-of-possession protocol so I present the user with a form asking for a mobile phone number and then send a verification code to that number via SMS and show another form requesting the verification code.

[pravi]

@tmolitor-stud-tu I discussed this in jdev room and singpolyma suggested using xep 0050, which they are using with Cheogram.

Quoting him "0389 doesn't seem to have a story about multi stage still AFAICT. So I'd probably stick with 0050."

Do you still think xep 0389 is better option than xep 0050?

[tmolitor-stud-tu]

That's completely wrong, section 6.4 mentions that the protocol allows for an arbitrary sequence of challenges until the flow eventually reches cancel or success state: After a response is received, if the server needs more information it MAY issue another challenge. For example, if the user has entered their email in response to a challenge, the server might send an email and then issue another challenge asking for the unique code sent in the email.

[pravi]

@tmolitor-stud-tu thanks for your feedback and confirmation. We will go with XEP 0389 and can update the XEP if we feel things needs improvement (like adding a session key for broken connections).

[lissine0]

I think this issue can be closed now that Quicksy for iOS was released