Navigate to https://app.ens.domains
Search your public address in the search bar
Look for "Primary ENS Name (reverse record)". If this says "not set", you will have to set the Primary ENS Name record.
To set the Primary ENS Name record, please click "My account", and select "Primary ENS Name".https://app.ens.domains/faq
Rep aims to serve as the internal reputation system within gm.xyz communities, similar to Reddit Karma.
Rep is specific to each community. For example, your rep score in c/gm will be different than your rep score in c/web3music. The score value depends on your engagement in each community--if your peers in your communities deem your content valuable through upvoting, your rep score will go up.
Communities are encouraged to reward high-rep users--either monetarily or with special privileges!
Rep can be earned through genuine interaction on the platform. If you're posting original content, commenting, and interacting with other users in a positive manner, you will see your rep increase in time. In a nutshell, rep is determined by how valuable other users on the site find your content. Rep is specific to each community.
Your followers/following is not directly correlated to rep. However, it may help as those followers will see your posts in their feed and could upvote your content as a result, but they are not algorithmically related to rep score.
We have a few systems in place to prevent people from gaming upvotes/rep or “rep farming”. Votes from high rep users count more. This is to prevent people from trying to game rep with a bunch of fake accounts. Rep is also not related to any form of speculative airdrop. Gaming this system is not encouraged, and you will be likely wasting your time.
Today, our technology stack runs on Amazon Web Services, and it is pretty much identical to the stacks of most traditional Web2 applications. Our reasoning for this is that building a social platform people actually want to use is difficult enough with traditional architecture. Trying to build one today on decentralized architecture would be 100x harder and prohibitively expensive. Thus, our plan is to "progressively decentralize". This will involve open-sourcing our code base, opening up our APIs , and eventually moving to decentralized architecture (e.g. IPFS, Arweave, StarkWare, etc.). And then, once we have achieved product/market fit, formed a robust community, and put in place a model that properly incentivizes sustainable operations, we will "exit to the community". This model borrows heavily from the playbook outlined by Jesse Walden and Andreessen Horowitz here.
Many people are skeptical of decentralized social networks for good reason. How will a decentralized network be able to compete with the engagement-optimized algorithms of Twitter and Facebook? How will it curtail the spread of misinformation or content that incites violence? Who will maintain it and push innovation forward? These are really tough questions, and we don't have all of the answers. But here's our long-term plan for gm.xyz and how we think we might be able to solve these issues over time.
The team behind gm.xyz hopes to progressively decentralize over time (following a playbook similar to what Jesse Walden and Andreessen Horowitz lay out here). This will eventually involve putting all of the platform's data on-chain. Once this is done, anyone will be able to build clients leveraging that data to give users the end-experiences they want. We hope this will resemble an evolutionary process with the best clients and ideas on how to solve the aforementioned issues competing against each other. This competition should hopefully result in a superior (and more diverse) social media ecosystem versus the one that exists today. One without the data-hoarding tech-giant gatekeepers that exist today.
Balaji Srinivasan, Vitalik Buterin, and Juan Benet also lay out some great ideas (that we mostly agree with) in this interview