accounts fails to find user-id except via HTTP syntax

[wxl]

The most recent README says to use the following to follow someone by user-id:

% madonctl accounts --user-id Gargron@mastodon.social -l5 # Last 5 statuses
% madonctl accounts --user-id https://mastodon.social/@Gargron -l5 # Same

This is wrong, first, because it doesn't include a command (it should probably be statuses given the comments), but also because the former specification does not appear to work:

$ madonctl accounts --user-id tone@emojidon.global follow
Cannot find user 'tone@emojidon.global': user not found
$ madonctl accounts --user-id tone@emojidon.global show
Cannot find user 'tone@emojidon.global': user not found

As a related test, adding the initial @ doesn't work, either:

$ madonctl accounts --user-id @tone@emojidon.global show
Cannot find user '@tone@emojidon.global': user not found

Using the second syntax to find the account-id and following with that proves to be just fine:

$ madonctl accounts --user-id https://emojidon.global/@tone show
- Account ID: 19891  @tone
  UID: tone@emojidon.global
  Display name: 
  Date: 2017-05-26 11:00:47.666 -0700 PDT
  URL: https://emojidon.global/@tone
  Statuses: 0
  Followers: 0
  Following: 0
$ madonctl accounts --account-id 19891 follow

And after having done that, the former syntax works fine:

$ madonctl accounts --user-id tone@emojidon.global show                        
- Account ID: 19891  @tone
  UID: tone@emojidon.global
  Display name: tone 🇯🇵
  Date: 2017-05-26 11:00:47.666 -0700 PDT
  URL: https://emojidon.global/@tone
  Statuses: 0
  Followers: 1
  Following: 0

Is this perhaps related to the fact that there were no followers on my instance? Is that the limitation of the (Mastodon?) API is that it can only search through what the local instance has access to?

[McKael]

Yes this is exactly the reason: if your instance doesn't know the account, it will not resolve it. Mastodon resolves the HTTP URLs, that explains it works with this form.

I'm not sure that's something madonctl should solve by itself, I'd rather hope the Mastodon API will improve. (But maybe the documentation should be clarified...)

BTW the Mastodon /search API has a resolve option, I'm not sure what it does TBH. Maybe madonctl search --resolve "tone@emojidon.global" would have worked?

[McKael]

Oh, and thanks for the missing command, I'll fix that! :)

[shellkr]

If you intend to follow a remote account that is not on your instance you are supposed to do..

madonctl accounts follow -r tone@emojidon.global

Maybe a similar syntax can be used with the show option.

[McKael]

The difference is that the follow remote is part of the API (the URI is resolved by the server).

Here the only solution I can see is a dirty hack turning @a@b.c into https://b.c/@a if the API call fails. That's not really pretty, but I can't think of another way.

[shellkr]

hmm.. then that is maybe a upstream bug? It is very inconsistent to have to use URL at some places and ID at other. Anyway.. when I think about it. The sanest way would actually be to remove the -r and have it tested automatically if the follower is on a remote instance. It is kinda to easy to miss that you have to use the -r. I can not see any practical reason why it should be separated from just typing follow <user>.

[McKael]

Sorry for the delay, I missed your comment.

I think the upstream API isn't very consistent, but the idea is that madonctl is an interface for all API endpoints and I wouldn't like it to magically change which API the user wants to use (the --user-id is some kind of magic switch that does an extra ID lookup but it doesn't handle all ID forms).

To follow an account the upstream API has different endpoints; with madonctl this is the same command with either -a (account ID) or -r (remote account URI).

Maybe what I could do is that when no flag is given madonctl tries to be smart and consider it's a local account ID if the argument is a number and a remote account if it contains a "@"?

[shellkr]

Yes, that would be a good solution. ;)

[McKael]

@shellkr With the commit above, there's no need anymore to use explicitly the '-r' or '-a' flags. (It still doesn't address @wxl 's comment that the https://yyy/@xxx and xxx@yyy forms are not interchangeable with Mastodon API.)

[McKael]

@wxl Regarding your initial question, yes, first your server could not resolve the user ID tone@emojidon.global because this account was not known. Once it has resolved with the URL search (https://emojidon.global/@tone) it has been created on your server and the former short ID can be used.

That's the way Mastodon works, not much we can do in madonctl. I thought about trying to turn automatically the short ID into an URL but that seems ugly and maybe not reliable.

Anyways, now you can provide any account format without having to think about which flag to use. If the user is not known to your server you'll still have to give the URL:

% madonctl account follow https://emojidon.global/@tone

Hopefully it's ok for you!

[McKael]

Closing since what I described last week is probably the best I can do (with Mastodon API) without going into too much hack...