Don’t know if this is the right place to create this topic, but I didn’t find any place that seems much better than here.
I thought it would be great if people could add an eth address to their Gather profile that could be fetched through the WebSocket API by using the player object, with an address that exists only if the player has set his eth address.
Please let me know what you think about this suggestion.
Unfortunately, that still falls into the catagory of a persistant player variable, even if it is read only. The same could be asked of a twitter handle, a steam username, or even a chess score. All of these would either need to be kept public or private, and the means of adding that data to your account would need to be implemented.
Do I think Gather will let Devs add variables to players? Sure, maybe. Do I think a variable I add to my players should make its way into your space? Unclear. There are pros and cons.
All this said, if you wanted to add data to a player, the “Affiliation” field in player data is hard for players to edit or modify, and does seem to be somewhat persistant within one space (meaning someone can log out, then log in and still have whatever was there before). You could stick an address in that and it would mostly save it.
Yeah as you say many times providers let you add optionally some links to some profiles that are deemed important.
There are probably thousands of services that implement a Twitter or a steam handle, a chess score, less so.
Twitter itself lets you add your ETH, so they considered it’s important enough to have it publicly accessible.
Is a mere suggestion that has its roots in the fact that gather wants to be closer to web3 projects, and in such a case allowing users to link an address for me at least seems a way to get closer.
And again this is not about attaching external info to a player is about getting info that the users provide to gather service…
Oh, I whole heartedly agree with the goal! Being able to integrate important pieces of data from bigger, mainstream social media/gaming/web3 platforms will offer a ton of great ways to offer new and exciting features.
Sorry if I came off as negative, I was more trying to boil down conversations I have had like this one over the last months.
To really get traction, the feature request board is another great place to post about it: Feature Requests | Gather.Town
I’m not sure if they have plans for it, but I think web3 tag over there would be great for compiling requests realted to that.
@andrei0x309 I pinged some people internally to gather their thoughts on the topic here - sorry for the late reply, things are just immensely busy. I think mostly I agree with Bills sentiment, but will add some further comment later on, hope that’s okay.
Hey! Sorry for the delay. I’m super on board with this kind of identity linking and I think it would be really useful. Main reason we haven’t done it yet is that we can’t keep up with all the great features that would help the 99%, let alone the smaller (but hype) fraction of web3 people on Gather. Plus once you add Ethereum addrs it makes sense to also add twitter, discord, etc, and this isn’t super sustainable. The more ideal version is to make it possible for 3rd party devs to link Gather identity with any other identity, and then we’re not a bottleneck
so tl;dr, this is possible but you have to do a little work on your end
for example, Lit Protocol is already linking ETH addrs with Gather uids to do some cool stuff
Yeah, no problem, when I made the topic I was already aware that you could use a player ID to link with another identity using your own service.
As you say is all subjective when it comes to what field is important or what is not, I agree that when you open the door to one field then that can lead to requests for other fields.
Saying it could cause a bottleneck yeah sure, it can happen if you allow a large number of fields, but the reality is even for 5 or 10 static social fields is nothing, how many are now over 20?
Also, you could make the fields opt-in for the servers option and disabled by default…
The main idea of having a field directly provided by gather is to expand data collection because is hard to disagree that having more methods to collect data has less success than having fewer methods to collect data.