Allow managing non-diaspora xmpp contacts via diaspora aspects

See https://github.com/diaspora/diaspora/issues/6089 for background


Note: This discussion was imported from Loomio. Click here to view the original discussion.

Proposal: allow managing non-diaspora xmpp contacts via aspects

As many people already have a non-diaspora xmpp accounts they use, allowing seamless integration would make the chat experience in diaspora better. Since contacts are primarily handled by diaspora aspects, having ability to modify them via aspects is natural.


Outcome: Considering all the good comments, withdrawing this proposal.

Votes:

  • Yes: 11
  • Abstain: 2
  • No: 9
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.

Since I haven’t experienced the XMPP chat on diaspora*, it is not clear for me. So far, here is what I’ve understood:
non-diasporian contacts are already accessible from the chat on diaspora*, the present proposal would push it a step further by managing these non-diasporian contacts. Am I right?

Technically it might be correct to separate XMPP- and diaspora-contacts. But for the user it will be hell to have two different mechanisms to handle his/her contacts. Especially when you think that 99% of all XMPP-contacts will be diaspora-contacts. I just want to have one area to manage my contacts not two.

Aspects are an important part of generating the streams as well as posting contents as we use them as a source to JOIN all the recipients together. Adding non-diaspora contacts creates an insanely large amount of complexity in the whole code base.

Note that this proposal is not about how this is implemented in the database. It is about the user-experience.

I would like to echo what @rasmusfuhse said, it could be implemented as a different backend and we only need to be able to manage these contracts from the main contacts page. It could be shown as a separate aspect altogether.

@theworldbright you have misunderstood this vote. The outcome of this vote will not affect project priority or force anyone to work on it. All it does is to allow anyone to interested in this issue to work on it and get it accepted in the main code base. If you feel those issues are more important for you, then you can add bounties for those issues.

@praveenarimbrathod Maybe I should have stated I do not want this feature until the chat is stable, the chat design is polished, and group chats are enabled. If someone tries to add this feature in before the features I mentioned above are implemented, it would complicate the implementation of those features. Do you think I should still switch my vote from disagree to abstain based on my argument?

What if the allowed us to add another xmpp account?

added 7 more days for more discussions as its controversial

Here I see two different businesses.

  1. Would you like to allow non-diaspora xmpp managing contacts via diaspora aspects?

If the answer to 1 is yes.

  1. you think this is the time to implement “1” or think we should wait until the chat is more mature.

Let’s go through some UX issues that we would have cope with if we would use aspects to manage non-diaspora XMPP contacts.

  • Currently you can start a conversation with all contacts in an aspect. Since some could be diaspora* contacts without an XMPP account and some could be XMPP contacts without a diaspora* account we would either have to disable that feature or we would have to explain to the user that he/she can only start a conversation with some of the contacts.
  • You can make contacts in an aspect visible to each other. AFAIK that doesn’t work for XMPP contacts so again you would have to explain that to the user or disable the feature.
  • On the contacts page you can click on a username to go to the profile page. That doesn’t work for XMPP contacts so you would have to explain to the user why some usernames are links and some aren’t.
  • You can send a post to selected aspects. All contacts in those aspects can see the post except for XMPP contacts. Again you need to explain that to the user.
  • What should happen when you try to add an XMPP-only contact to an aspect with disabled chat?
  • What should happen when you have an XMPP-only contact in an aspect and disable the chat feature for that aspect afterwards?
  • How do you add XMPP-only users to your contacts?

@steffenvanbergerem it can be named “XMPP only” and added at the end of list of aspects in contacts page. It can be managed separately.

@praveenarimbrathod Then those wouldn’t be aspects but XMPP groups that we display on the contacts page. That is not what this proposal is about.

@steffenvanbergerem my requirement is a way of adding non-diaspora xmpp contacts from diaspora and adding them to aspects seemed like the most natural thing to do. But if that is too complex and confusing, then doing it separately would also do.

update: corrected

Proposal:

allow managing non-diaspora xmpp contacts via aspects

Your last comment:

adding non-xmpp contacts from diaspora and adding them to aspects

Now what is it? non-diaspora contacts or non-xmpp contacts?

@jasonrobinson I think Steffen outlined how this is also harmful to UX not only code complexity. Do you disagree with his points?

@jhass sorry for the confusion, I meant non-diaspora xmpp contacts only.

@jhass yeah, not through aspects. Thinking more specifically at this, changing my vote…

Proposal: allow managing non-diaspora xmpp contacts via contacts page

We need a way to add, remove or edit xmpp only contacts from diaspora web interface. It can be separately handled from aspects.


Outcome: It is too early, we’ll revisit it when chat is stable

Votes:

  • Yes: 5
  • Abstain: 2
  • No: 9
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.

@praveenarimbrathod can you extend the proposal please? 3 days is way too short :slight_smile: A few weeks at least imho.