Accounts and personas

Resonate has migrated services off Wordpress. This documentation likely needs review and an update.

Resonate is currently set up on Wordpress. Soon we will be migrating to a new infrastructure and website. Account management will change. This guide explains the functionality of account types pre- and post-migration.

Before migration (former)

Resonate is currently spread out between different sites which you have to log into separately.

  • The main site, where you can create and edit your account
  • The resonate player, where you can listen to music
  • The dashboard (currently only available to admins)

At this time, to post in the Community Forum, you need to create a separate Forum Account. You are encouraged to use the same email you used for your listener account or artist account.

Account types

Forum Account

Listener Account

Artist Account

Label Account

  • self sign-up currently disabled

Switching account types

Listener Account → Artist Account

To change a Listener Account to an Artist Account, visit this page. For changes between other account types, contact

After migration

Account types

[ needed ]


Users will still be able to log into Wordpress via

Why login to Wordpress?

For users, they can delete their Wordpress data.
For admins, they can use the interface to assist users.

Currently, track ownership is tied to Wordpress user ID number. This will continue after migration. Future plan is to build a system where track is associated with a (1) usergroup and (2) an owner account: artist, label, etc.

Accounts migration

Not all accounts will be migrated. dummy accounts won’t be migrated; they will become Personas under their label.

After migration, the artists affected could create an Artist Account on the new website and claim their Persona. A process will need to be established for this.



@auggod Currently, someone who creates a Listener Account or an Artist Account is not able to use this account to log into the forum. They have to create a separate Forum Account, although they can use the same email as before.

After the wordpress migration, will a user be able to log into the forum using one of these accounts? Will forum login be an integrated part of the ID server?

Yes, this is part of the plan.


Recently a suggestion was made to scrap the custom ID server in favor of a third-party tool. I asked @merefield a question about this, as I had a feeling that the reasoning may have had to do with the personas model (where a single account can be represented by multiple personas, which is very necessary for most artists). My question was:

based on your understanding of the code, would these scenarios (where someone could even have different stats, stream2own credits, etc under a distinct persona) have led to a decision to have our own custom ID server? Or are all of these scenarios just as easily solvable with a third party API?

Robert’s response was:

There are two parts to this:

  • Authentication: who you are: this is what the Resonate id server is mostly concerned with
  • Authorisation: what you can do, this is where the Resonate User API focuses and is responsible for handling the bespoke User Persona logic.

Go is definitely a very good choice for this mission critical software as is reliable, harder to make buggy (if it builds its likely to run), secure (if you follow the standards), high performance and scalable.

The cost issue is double edged. You could go for some third party Id server, but yes, you will be forced to integrate this and consider your bespoke requirements. On top of that you will be at the whim of a 3rd party in terms of your licensing costs. I appreciate it may free you of dealing with some of the detail (but be wary of the custom work required to make an integration work and its maintenance which may also require specialist knowledge). Out of the frying pan and into …

I appreciate it’s hard to source good developers full stop, and good back end developers who are professional even more so and sometimes that’s going to be about money. Perhaps there will be an outflow of devs from the crypto space as the reputation of that sector is taking a bit of a big battering atm?

I think one way to reduce your costs is to simplify your architecture as per the recent strategy proposal. I would definitely focus on eliminating Wordpress and its database and absorb as much as possible into as few technology choices as possible.

Hopefully this info will help in making a sound decision.


Thank you Peter for constructing this intelligent and informative post and for bringing it into the community forum.


I wanted to comment on the argument :

The whole reflexion behind moving away from Go was never tech-based and this is a tech-based answer. From all the talks we’ve had, it was never implied by either @psi @piper @jeremy or anyone that Go was a bad choice tech-wise, our assumptions were more the opposite (“this has probably been done for very good tech-savy reasons” give or take) and our conclusions were pretty much everything @merefield wrote in this answer bar a few details.

This being said, our conclusion was that Resonate should be built around the forces it has and the people willing to build it, through a structure based not only on their knowledge but on their capacity to transfer that knowledge to others and onboard many more enthusiast collaborators. The reflexion wasn’t a tech-reflexion, it was a social-community-labor decision. If we were a regular company with a regular operating budget an order of magnitude higher with hundred of thousands of dollars, we could choose “the best tech” and leave it at that because then our only problem would be to hire the people we need and if people want to come and help and we felt like being open to everyone helping out despite being a regular company (it would be a weird way to function but let’s imagine), we could maybe pay them to learn Go and build their own toolsets and give them time to do it 1/ without detracting from building the platform in the meantime 2/ so that once they have the knowledge they’re ready to deal with the most complex aspects of the platform. Again here it’s not about tech but workforce organization.

So sometimes the best code-tech dev-wise is not the best social-tech community-wise. Our conclusion was that Resonate has attracted many talents other the course of the last year and that Go has been a hurdle that’s stopped them to trully contribute meaningfully to the platform, so that means the current social engeneering of society makes Go not the best tech for who we are as a company relying on enthusiast and volunteer work.

Then it becomes a matter of considering what’s worse : a great tech with no devs to catter for it, or a slightly less great tech with an actual team that speaks the same language, is used to professionally deal with it and can handle developpment and feature implementation over the course of several months.

Sure we could bet that someday maybe there’ll be a swarm of devs coming knocking on our door because VC money stopped pouring billions into crypto metaverse and other crap (which is not happening right now, they’re just getting started crypto winter or not) and the logical follow up is volunteering for us despite their expensive skillset being wanted elsewhere, but that would be building the platform tools around the elusive idea of people we don’t know and can’t say for sure are there and willing to build it.

Meanwhile, devs DID contribute this past year, did build, did raise awareness around the tools we use, what they’d need to help out more (despite already having given an incredible amount of their time to this community all of it for free) and to me this kind of social-ingeneering matters more than the right tech.


Thank you @LLK for clearly stating a very reasonable POV. Helps immeasurably to create some context and I totally see the practicality in the position.

My reasoning for jumping in on this and asking Robert some questions was less about the programming language (Go) and more about having our own user identity system rather than use a third party service. This is Robert’s mention of the “bespoke User Persona logic” topic that I raised and whether we’d even be able to do what we need (provide a complex persona system) via some third party code. Also Robert’s point about the costs needs to be understood too.

  • can we get the same user persona complexity with a third-party service?
  • what will be the costs associated?

I’m honestly not biased either way. I just want to make sure we’re making a sound decision that isn’t going to cause problems a year down the road.

So then, who is best situated to answer those questions? And are there more critical questions to be asked? Again, this is less about Go and more about whether we need a bespoke User ID system. (Perhaps the short term is use a third-party and then go back to custom a year from now when we’ve solved so many other challenges?)

I think Robert’s response is correct in that there are two things here.

User identification, and user permissions.

For user identification there are a number of solutions out there. There’s our own ID server (, written in Go) which, as far as I can tell, is an incomplete implementation of OpenID, but functional.

There’s stuff like Auth0, which for the first 7000 users is free to use. Auth0 is what I would have recommended Justifay uses. I’ve worked with Auth0 a lot and I like it.

Then there’s more “plug and play” stuff like this node-oidc-provider library, which is what I think Resonate should switch to (alongside the switching off of Go). It’s community maintained but we implement all the interfaces (whereas Auth0 implements all of these if you use them).

But we do have a functioning identification system at the moment at, so working on that seems less of a priority to me.

For user permissions (which to me is the toggling between different viewpoints of the app) I personally haven’t seen anything that’s plug and play. You can store permissions, groups, and roles in Auth0, but you’d still have to implement the UI of it. I’d still advocate for what I put in the mattermost, which is more of a “everyone has the potential to do everything, but things are defined by user flows, not user roles” (aside from admin, moderation, etc). Distinguishing between musicians and listeners I’m not sure is useful. Like Jeremy has pointed out elsewhere, we shouldn’t be conflating the UX concept of “personas” with permissions and abilities on the system.


Putting a +1 underneath @psi’s response above.

I also want to say that using a third-party service doesn’t lock us into a lack of complexity (or lack of support for personas) in that we can build out and upon a third-party service. I want to underscore that it seems that Resonate has historically fallen into the “not-invented-here”/“we need to reinvent the wheel” trap and there’s a lot of wonderful third-party open source libraries available to use - and in this instance, taking advantage of the power of open source software is not only a really strong (and not limiting) route to take, but also an efficient use of resources and our dev time.