Sounds like a good plan!

Excellent idea.

I really like the idea.

Also, if you want to keep existing lingo between different services, these “client accounts” are usually called “app passwords”. Maybe itʼs a good idea to stick to that name so users may know what this is all about.

Support IndieAuth as per https://roadmap.libre.fm

• A domain name is potentially 255 characters.
• User with a very long domain name signs up via IndieAuth
• Needs an app password

Please take a look at https://bored.city/demo.html and let me know what you think. @foocorp/beta-testers would love your feedback especially.

Actually:

The maximum length of each label is 63 characters, and a full domain name can have a maximum of 253 characters.

@mattl Use case: Mobile phone as audio player with a mobile scrobbler running in the background.

The username generated seems okay.. a bit long, and the generated string at the end would be a pain to hunt and peck. The password would be very difficult to enter.

I'm not sure there's a good way to go about this for the mobile case.

Why new username + password and not only a token as Listenbrainz implemented it?

@virtadpt why wouldn’t you copy and paste it once?

@millette where are you quoting that from?

@jcorporation I’m not paying much attention to ListenBrainz at this point in development of this. Are you saying they use a token for clients instead of a unique username? Do they support IndieAuth?

I do not think they support IndieAuth. IndieAuth is also new for me…

Using only an Access token for Clients is a Common implementation, not only at Listenbrainz.

@mattl That's a good point.

@jcorporation which clients? I’ve not seen a client ask for a token. Perhaps you can share a little more about how you’ve seen that work?

Last.fm’s own implementation of usernames is a 2-15 character name. I believe we require 4 characters minimum right now and 16 characters maximum.

Here is my implementation for a ListenBrainz scrobbler: https://github.com/jcorporation/mympd-scripts/blob/main/ListenBrainz/ListenBrainzScrobbler.lua

As you can see, I submit only an Authorization Header with a token. This is the easiest for scrobbling Clients.

Official doc: https://listenbrainz.readthedocs.io/en/latest/users/api/index.html

A lot of the clients I’ve seen take a user name/password.

If Authentication is as simple as the token attempt to implement for a client it is good in my perspective.

I don’t see any reason we should need to limit these but maybe we’ll let everyone have 50 such username/password combos? I suspect most people will use two, maybe three?

What is the benefit of putting a limit on it? Is there a security reason? Keeping someone from being a jerk and generating millions of records?

I'm not saying I need more than 50, I'm just curious as to what a limit gets you.

A limit makes sense when we’re talking about hundreds of thousands of users.

From Security perspective a Limit is always a good idea, even a high one.

If Authentication is as simple as the token attempt to implement for a client it is good in my perspective.

I'm not sure what you're saying here. Lots of clients, including MPD support a cleartext password and username. The password is MD5 hashed right now. I would love to move away from this.

It should be easy for a client to submit the credentials in a scrobble request. The easiest is a token in the authorization header in a https request.

Hashing the password with MD5 and storing it in the backend is clearly not a good idea.

@jcorporation I think you're talking about new clients?

I'm talking about the vast number of existing clients we already support. They're never going to change. This mechanism will help users by separating the existing username/password combination with app passwords for clients.

Correct, I talk about new clients.

Okay. That’s off-topic for this issue.