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

refactor: decode punycode domains for the UI #7748

Closed
wants to merge 2 commits into from

Conversation

Johann150
Copy link
Contributor

What

The function getAcct is improved by a getAcctUi function. It returns a Unicode version of the domain name, instead of the punycode version. Also the acct function, which was only an alias for getAcct is refactored and removed. It was left over from the Vue3 migration.

There are a few places where getAcct is not replaced (yet):

  • src/client/components/post-form.vue & src/client/ui/chat/post-form.vue
    uses account name in a post, will MFM decode IDNs correctly? if so getAcct should also be replaced with getAcctUi here because the user name is show to the user.
  • src/client/pages/my-antennas/editor.vue
    will antennas correctly recognize IDNs?
  • src/server/api/limiter.ts
    This could put IDNs in log files. Does the database, log and syslog protocol all support Unicode for this? And should IDNs be used here?

Why

Punycode was not always decoded in the user interface. For example:

old screenshot
new screenshot

Additional info

related: #5826

@syuilo
Copy link
Member

syuilo commented Sep 4, 2021

Thank you!
One concern is that when a user copies acct, the punycode will still be decoded when pasted, and will not be recognized correctly when mentioning, etc.

@Johann150
Copy link
Contributor Author

Johann150 commented Sep 4, 2021

Yes I see. That is also why I did not change anything in post-form.vue yet, so autocompletion will currently still insert the punycoded name.

But as a user I would expect that an IDN would be correctly recognized if I type it in manually or copy it from somewhere else like Mastodon or a web page. So I think this is another issue in MFM, that we should solve too. Do you agree?

@syuilo
Copy link
Member

syuilo commented Sep 5, 2021

We do not want to interpret unencoded punycodes, because MFM should be parsed according to the specification. (As well as not interpreting URLs that are not percent encoded)

Perhaps we need to make it so that when a punycode-decoded acct is pasted into the submission form, it is automatically encoded. However, for users who are not familiar with punycode, they may misunderstand that it was not pasted correctly.
The extent to which Misskey will support punycode may need to be considered.
So, I'm going to put this PR on hold for now🙏

@Johann150
Copy link
Contributor Author

Sure 👍

I think I will open a separate issue for discussion?

@Johann150
Copy link
Contributor Author

When misskey-dev/mfm.js#86 gets merged, MFM will be able to parse IDN mentions correctly, which will check the first item off the list.

The implementation of acct has been changed so that part now has to be solved as misskey-dev/misskey.js#32

@Johann150 Johann150 closed this May 15, 2022
@Johann150 Johann150 deleted the account-punycode branch May 18, 2022 14:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants