Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PEP nicknames from XEP-0172 #1867

Closed
wants to merge 1 commit into from

Conversation

bodqhrohro
Copy link

How to test the functionality

  • Setup telegabber
  • Switch to the roster window
  • Change some chat name at the Telegram side
  • Look if it's changed in the roster

I ran valgrind when using my new feature

==4147910== Memcheck, a memory error detector
==4147910== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==4147910== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==4147910== Command: profanity
==4147910== 
==4147910== 
==4147910== HEAP SUMMARY:
==4147910==     in use at exit: 1,849,573 bytes in 1,554 blocks
==4147910==   total heap usage: 1,551,248 allocs, 1,549,694 frees, 87,668,537 bytes allocated
==4147910== 
==4147910== LEAK SUMMARY:
==4147910==    definitely lost: 1,080 bytes in 15 blocks
==4147910==    indirectly lost: 2,125 bytes in 41 blocks
==4147910==      possibly lost: 832 bytes in 14 blocks
==4147910==    still reachable: 1,842,968 bytes in 1,457 blocks
==4147910==         suppressed: 0 bytes in 0 blocks
==4147910== Rerun with --leak-check=full to see details of leaked memory
==4147910== 
==4147910== For lists of detected and suppressed errors, rerun with: -s
==4147910== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Copy link
Member

@sjaeckel sjaeckel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Will you also add the possibility to set such a nickname? as FMU now you'd have to use a different client to set it.

==4147910== definitely lost: 1,080 bytes in 15 blocks

where do those lost blocks originate? I'm mostly certain they're not lost in your feature, but still it'd be nice to know. Feel free to attach a logfile.

Comment on lines +54 to +60
xmpp_stanza_t* event = xmpp_stanza_get_child_by_name_and_ns(stanza, STANZA_NAME_EVENT, STANZA_NS_PUBSUB_EVENT);
if (event) {
xmpp_stanza_t* items = xmpp_stanza_get_child_by_name(event, STANZA_NAME_ITEMS);
if (items) {
xmpp_stanza_t* item = xmpp_stanza_get_child_by_name(items, STANZA_NAME_ITEM);
if (item) {
xmpp_stanza_t* nick = xmpp_stanza_get_child_by_name_and_ns(item, STANZA_NAME_NICK, STANZA_NS_NICK);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be simplified by using xmpp_stanza_get_child_by_path()

Suggested change
xmpp_stanza_t* event = xmpp_stanza_get_child_by_name_and_ns(stanza, STANZA_NAME_EVENT, STANZA_NS_PUBSUB_EVENT);
if (event) {
xmpp_stanza_t* items = xmpp_stanza_get_child_by_name(event, STANZA_NAME_ITEMS);
if (items) {
xmpp_stanza_t* item = xmpp_stanza_get_child_by_name(items, STANZA_NAME_ITEM);
if (item) {
xmpp_stanza_t* nick = xmpp_stanza_get_child_by_name_and_ns(item, STANZA_NAME_NICK, STANZA_NS_NICK);
xmpp_stanza_t* nick = xmpp_stanza_get_child_by_path(stanza, XMPP_STANZA_NAME_IN_NS(STANZA_NAME_EVENT, STANZA_NS_PUBSUB_EVENT), STANZA_NAME_ITEMS, STANZA_NAME_ITEM, XMPP_STANZA_NAME_IN_NS(STANZA_NAME_NICK, STANZA_NS_NICK), NULL);

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah, nick is NULL this way, and it's non-trivial to debug where exactly does it fail (looks OK to me, huh :/), so I'll probably leave it intact for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, as I forgot that you have to give the full path, i.e. this should work:

Suggested change
xmpp_stanza_t* event = xmpp_stanza_get_child_by_name_and_ns(stanza, STANZA_NAME_EVENT, STANZA_NS_PUBSUB_EVENT);
if (event) {
xmpp_stanza_t* items = xmpp_stanza_get_child_by_name(event, STANZA_NAME_ITEMS);
if (items) {
xmpp_stanza_t* item = xmpp_stanza_get_child_by_name(items, STANZA_NAME_ITEM);
if (item) {
xmpp_stanza_t* nick = xmpp_stanza_get_child_by_name_and_ns(item, STANZA_NAME_NICK, STANZA_NS_NICK);
xmpp_stanza_t* nick = xmpp_stanza_get_child_by_path(stanza, STANZA_NAME_MESSAGE, XMPP_STANZA_NAME_IN_NS(STANZA_NAME_EVENT, STANZA_NS_PUBSUB_EVENT), STANZA_NAME_ITEMS, STANZA_NAME_ITEM, XMPP_STANZA_NAME_IN_NS(STANZA_NAME_NICK, STANZA_NS_NICK), NULL);

@bodqhrohro
Copy link
Author

Feel free to attach a logfile.

prof1.txt

Copy link
Member

@jubalh jubalh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your feature!

Regarding CI:

@jubalh
Copy link
Member

jubalh commented Jul 13, 2023

A couple of questions:

How should this play together with /nick (setting your own nickname in a MUC) /roster nick (assigning a nickname to a user in your roster). Should a nick sent by the contact or the nick I assign via /roster nick have a higher priority?

Will you also add the possibility to set such a nickname? as FMU now you'd have to use a different client to set it.

?

@jubalh
Copy link
Member

jubalh commented Jul 13, 2023

From our MUC:

jubalh: pep.: do you support xep0172 in poezio? I would have some questions how to handle it: https://github.com/profanity-im/profanity/pull/1867#issuecomment-1633801969
pep.: I think we do but not really. I'd like to. I started something here about it: https://codeberg.org/joinjabber/support/issues/6
pep.: But for your question,  
pep.: If a nick is set manually in a MUC I'd use that rather than the global set nick
pep.: Same for the roster.
pep.: In general, if a user has done something manually for a more detailed level I'd use that rather than the global setting (172)
jubalh: pep.: I agree. Thanks for your input!

So I think we need to check if the user did set a nickname for person in their roster and only if they didn't use the nick that we get over this XEP. Same for MUC.

Could you add such functionality?

And do you plan to also implement the setting of the nick?

If you need any help or guidance don't hesitate to ask here or contact us in the MUC.

@bodqhrohro
Copy link
Author

How should this play together with /nick (setting your own nickname in a MUC) /roster nick (assigning a nickname to a user in your roster). Should a nick sent by the contact or the nick I assign via /roster nick have a higher priority?

From the experience with my transport, users have different expectations. Some indeed prefer to set contact nicknames manually, and are frustrated when they are updated automatically. Other users are rather frustrated when they don't see relevant updates of the nickname (especially if they have saved a nickname provided in a subscription request, which in some clients is equal to setting it manually).

I suppose it should be a configuration option then, and the default should be to respect the nickname from the roster first then, as recommended by Modern XMPP.

And do you plan to also implement the setting of the nick?

Maybe, but later. Setting the nickname via PubSub seems to need some server-side support, so I'll need to prepare it for testing first.

@jubalh
Copy link
Member

jubalh commented Jul 14, 2023

I suppose it should be a configuration option then, and the default should be to respect the nickname from the roster first then, as recommended by Modern XMPP.

Yes configuration option would be good.

Taking roster nick in MUC doesn't make much sense to me since it could be that I want to reply to a user and write "John Tolkien: how are you doing?" because in my roster he is named like that. But everyone else sees his nickname as "JRRT" because that's what he set when joining.

Maybe, but later. Setting the nickname via PubSub seems to need some server-side support, so I'll need to prepare it for testing first.

Ok, great.

Copy link
Contributor

@H3rnand3zzz H3rnand3zzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, fix the nesting, add XEP support information to .doap file and disco (XEP-0030, XEP-0115, if it's recommended/required by the XEP that you are adding).

Thank you for your contribution.

if (items) {
xmpp_stanza_t* item = xmpp_stanza_get_child_by_name(items, STANZA_NAME_ITEM);
if (item) {
xmpp_stanza_t* nick = xmpp_stanza_get_child_by_name_and_ns(item, STANZA_NAME_NICK, STANZA_NS_NICK);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if you want to follow this way, your nesting is too deep. Please, follow the best practices https://testing.googleblog.com/2017/06/code-health-reduce-nesting-reduce.html

@jubalh
Copy link
Member

jubalh commented Sep 11, 2023

@bodqhrohro ping :)

@bodqhrohro
Copy link
Author

I see no real-life use for setting the nickname via PubSub and thus not sure what to do and why.

I forgot that my transport also sends the nickname in presences, and I implemented PubSub later than that specifically for Gajim as Gajim ignores the nickname in presences and uses only nicknames from PubSub. The person who I made this patch for finally implemented their own patch which takes the nickname from presences, as they found it easier; not sure if they intend to merge it upstream at all. Later I discovered that this actually violates the standard, as it specifies that regular non-subscribe presences MUST NOT include the nick.

@jubalh
Copy link
Member

jubalh commented Oct 9, 2023

Do I understand you right that you think your PR is obsolete?

@bodqhrohro
Copy link
Author

I'm not sure about that, as the other patch violates the XEP, but as of now it Just Works™. PEP is also not a great solution for the task, given that the roster name is anyway the highest priority according to modernxmpp spec, yet it works in Gajim. Slidge implements roster sync via a special privilege, and we probably would go this way eventually too (but that won't work for the users from other servers).

As of now, I'll probably close this PR and reopen it later if we come up with some decision. When more important features are implemented, I'll anyway return to the problem of presence flood, as they consume traffic excessively, and those out-of-spec nickname presences are a part of it.

@bodqhrohro bodqhrohro closed this Oct 9, 2023
@jubalh
Copy link
Member

jubalh commented Oct 9, 2023

As of now, I'll probably close this PR and reopen it later if we come up with some decision.

Feel free to reopen or create a new patch when you feel like it!
All improvements are welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants