Ramon Morcillo


Maker. Problem solver. 🍉Fruit Fanatic. 🏄‍♂️Nomad Surfer Constantly creating to improve myself and those around me.
Joined January 2023

Thanks @closedloop for that great comment. I 100% agree and think will opt for B to abstract my business from the issues of the accounts connected :)

Thanks Rod for the tip. We already have a "Pay at the property" fallback 😉

Hey Jaku, do you mean you create usernames once the user signs in based on the username from the oauth?

What I do in Mapmelon is creating the username from the email. I get the first letters plus add some random numbers.

Then I let the user update it if they want.

This way I make sure there will be no duplicates.

Go and give it a try here www.mapmelon.com/auth/signup

Yeah, so we would use the username of the account that is logging in with the OAuth provider that the user picked. The services we use already have a username for the user, which is where our problem basically comes in. Our users are content creators, so they may already have a following under these names, but we know there are some users that might be popular on Twitch with one name, and another user with the same name is popular on TikTok.

In our case, if two users were to log in to our platform and we used their names as an identifier in a URL, that would cause an issue when having them share a link like {domain}/{username} to their userbase.

I see you have Google and Facebook, and you ask for a name on signup but this works differently than what we are looking to do since the username is coming from the provider.

One issue I see with having the name getting set on a first come basis from one provider is that it can then create a domino effect of requiring users to find a new name on login. The first user comes in as Bob from Twitch, and the second user comes in as Bob from TikTok, we then ask TikTok Bob to change their name, so they change it to Tom. Now Tom from Twitch logs in and has to change their name, and even Tom from TikTok has to do the same.

I'm leaning towards a URL structure like {domain}/{service}/{name} so users can keep their names, and users trying to find their creator on our platform might be able to still guess another creator's URL if they already have an existing creator's URL. Just something about including the service in the URL comes across as tacky or weird I guess.

I'm not sure there really is any other solution that can meet my criteria, even if we went with the Discord route and the # didn't cause issues, users wouldn't easily be able to guess their creator's URL.

For what’s it’s worth I’m never a fan of this approach, as it temporarily exposes part of my email address to other users. Assuming the username is public.

How does it expose the email address? These names come from the creators' names on platforms like Twitch/Twitter/Discord. So twitch.tv/jaku my link would be mywebsiteservice.com/twitch/j….

I suppose if jaku is part of my email this is true, but they'd have to assume the rest of the email and what provider I'm using to receive email?

Unless I'm missing something here?

This was a reply to @reymon359 😅

Ah! That would do it. I see now, thanks for the clarification.

Hey @hugopenna

As we want more users atm we will implement the free one at least for now.

Maybe in the future move to the second one.

Thanks for your insight!

Hey Alejandro thanks for your feedback. As it is a pre launch subscription we didn't think about a free plan for now, but will consider it in the future 😄

Thanks @hiro1107 , we actually plan to do that in the future through a booking system 😊

Thanks @klaaz0r for the comment, you are right that we don't want to obstacle the user growth, that's why we will focus on the coliving spaces and not the users for the monetization 😄

I don't know your numbers, so I can only make some guesses but what I would do is test payments for a small group of users. but keep it free for most. What I would want to know is if this is something people want to pay for. If yes, keep growing and keep it free (again this depends if you have enough on the supply side of course)

Thanks @alvivanco , I had not considered that option actually. Will keep it in mind 😉