On chain Guilds platform- Come help us out!

Ok, so can I request for the marmaj Guild?

Realize that this platform is supposed to enable the guilds to grow in size/activity while facilitating some data gathering/metrics around that activity to inform and report on the successes being had by the guild’s program. However, I see some potential pitfalls arising to consider:

  1. Centralization of guild operations in this platform. Depending on the guild, you can probably already find many of these ideas implemented in various ways. If you focus on standardizing them or offering as a service through this platform - we risk moving away from the autonomous nature of the guilds and the innovation that arises from the different ways of addressing the same issues. Obviously the counter to that is that efficiencies and best practices can be achieved by everyone implementing the same way.

  2. Consider prioritizing composability going forward. That’s part of the whole idea of the open web. So, instead of building all these things into this platform - enable teams to build them separately and let guilds decide which to implement in their activities. For example:

  • profiles and notifications are something that can already be plugged into any application (and that would go for Guild information as well) in a decentralized manner (built on integration with Ceramic/NEAR). Profiles that then follow that person across any dapp on NEAR which is the way this needs to be looked at vice building another module for this platform. Or, if its deemed existing solutions aren’t good enough, aim to support them, or build a new one, but then give the option as to which a guild can implement (integrate them all at the platform level).

  • rewards - sounds a lot like what Cheddar is trying to do, but then let’s also ask the question as to why a guild needs to use this reward system - maybe they are issuing their own tokens as rewards or use something else.

  • onboarding - might be beneficial to build out a standardized - new-to-NEAR onboarding flow that incentivizes someone to get setup with a wallet/learn how to use it. I’m guessing most guilds with activities on chain have their own way of bringing their prospects through this and it doesn’t require a whole lot of guild identity customization - pretty much a standard flow.

  • members - as it is effectively a type of registration, seems logical to have the functionality in this platform if a guild wants to use it to enable its members to register their affiliation to their guild. However, others may already have on chain membership registration setup for their guilds (I do). I would not be keen on having to direct my members to go through two registration processes to be counted as active members of the guild. The platform needs to be able to draw data from relevant contracts (although those not using the platform for the key metrics needed by NEAR should make it available somehow - e.g., through a subgraph on The Graph for easy consumption/integration)

I guess in general, I’d rather see this platform focused strictly on registration and verification to enable guild discoverability across the ecosystem and wherever possible, it needs to do it in a Web 3 way without centralizing functionality:

  • why should I need to rely on a centralized entity (maintainer of the site) to add my guild to the directory?

  • why can’t the site just identify which guilds are whitelisted (approved NEAR guilds) and filter the display accordingly?

Would recommend thinking of ways to draw in and aggregate data from guild activities as they are currently occurring vice aiming to bring all guilds onto one platform. That might mean asking guild’s to do things on their end to make relevant data accessible to the platform (and others like it).

I’m not saying to not build a guild’s platform. Just saying that care needs to be taken not to replicate a web 2 system without reimagining how it could function with web 3 tools/adhere to open web principles.

Likewise, caution against creating a system where only guilds who use the platform and its tools are going to find favour or be able to participate fully in the ecosystem. If they aren’t listed or their activity can’t be measured through a platform integration that provides a dashboard of guild ecosystem activity then they are disadvantaged (intentionally or not).

Of course, guilds may also have a responsibility to report activity for data aggregation in a manner that can be automatically consumed as part of their obligations as participants in the ecosystem (although that obligation is debatable).

I don’t know why my responses to these things always end up being so long - apologies for that :slight_smile:

3 Likes

Hi Chloe,

The guilds are being pulled from the ES map: ecosystem/entities at main · near/ecosystem · GitHub

So if you update info in there, it’ll show up on the guilds platform. And yes, we can definitely include MarmaJ in the next phase roll out in 1-2 weeks - @cloudmex-alan please make a note. :slight_smile:

Hi Aaron,

As always, really appreciate the feedback.

The hope and goal is that every new guild, in their onboarding process, are advised to add their guild to the ES map on github and the ES team reviews the PR and adds them, which is the centralized repository. I don’t know if centralization at this stage is necessarily a bad thing since this only helps guilds list themselves in any aggregators that use the github repo as the back end.

The main reason why I think a centralised solution is helpful here is because we also want to include the ability to state activity levels of guilds so that a new contributor knows which guild is active or which ones are in-active. People are usually eager to update their guild info on the repo when they start, however, if they have other priorities etc in life and want to stop running the guild, they don’t often come back update the status of their guild. This is in fact the problem statement here and if there are decentralized ways in which we can indicate this, that would be ideal and we should definitely look at implementing that.

:100: agree! The idea is that the end user experiences everything in one platform instead of being re-directed to different places, which breaks the flow. For example, I really like stats.gallery profiles and we are also planning on implementing the “transactions” feature to gauge “activity” of the guild members- in our case the definition would be at least 2 on chain tx in 1 month. But I suppose this is where ceramic profiles can also help, in the future iteration where we can have guild member profiles too.

On onboarding, we were thinking about custom on-chain activities and quests. For example, if I’m new to the NEAR Music guild, by basic steps might be:
Step 1: Set up a mintbase store

Step 2: Mint a music NFT

This is obviously heavily inspired by Stats Gallery quests, but thinking more along the lines of how can we make it more interactive, so that if mintbase contract is the one associated with a guild, and if i deploy my own store or have my own nft minted, it recognizes that. In terms of onboarding, it helps the guild get a member that’s already completed the bare minimum, so perhaps their quality of engagement going forward would be much higher.

Again, i realize that creating custom on chain quests for onboarding might be really challenging given the different guilds, but I think it would be interesting for us to think along the lines of creating that infrastructure.

Creating a whitelisted list of guilds would also be a form of centralization right?

Completely agree with this. Definitely keeping in mind that there’s a lot more to community building and value addition to the larger ecosystem than just getting their members on chain and have them be more active on chain. This is also the reason why we haven’t reflected anything from this platform into guilds funding because this is going to be a WIP for a while, until we capture these nuances and only if we reach a stage where guilds feel like a large part of their work might be represented in a platform like this, will we make that switch. Until then, it’s going to be a lot of work into understanding how guilds use this, what features are useful, and keep building.

I love reading through them! I know that @chronear is putting together a working group around the platform. Thinking deeply about the problems we can solve with a platform like this is really important and I’m glad we can have your feedback and help in building this out.

2 Likes

I think this is not what we are proposing with this platform, right now NF have a picture of what is happening on guilds looking for more traditional data as discord users. What this platform propose is to have a bigger picture on what is happening with guilds and their members based on chain activity. More data, more knowledge, better decision making.

Note taken!

Would take inspiration from here to think in next features to be developed. Ceramic looks great to be included.

Totally agree! Web 3 is evolution, so on we have to focus in see what things stay as done or what new things would replace old stuffs

Good chats with @chronear and @shreyas this week - inspired me to really get into this over last couple days (much to the dismay of my over projects :slight_smile: )

I would suggest the guild’s platform can actually be separated into several components. At base level, recommend focusing on these processes first:

  • Guild Onboarding - make it easy for guild leaders to follow a pathway that has them create/connect an admin account for their guild, register the guild, and create the guild’s profile.

  • Individual Onboarding - make it easy for an individual to follow a pathway that has them create/connect an account, register it, and create a profile (persona) for it.

  • Guild Admin - provide interface where a guild leader/authorized people can administer guild functions (and move away from PR requests on Github). Suggest following are important first steps:

  • ability to update guild profile information, change logo, contact info, etc…
  • verify status of a guild (in good standing or not, endorsed by NEAR or not, etc…)
  • set certain accounts (those who review Guild applications) as verifiers - give them the ability to change toggle guilds between verified/unverified.
  • change guild tiering level (and provide means for applying for tiers or automatically advising when a guild is ready to move to next tier based on some kind of metrics)
  • guild analytics - see activity and visualize guild growth/stats
  • Guild Discoverability - guild onboarding will potentially make lots of information about the guild available. It can then be pulled/queried/searched and displayed in a manner that allows individuals to browse the guilds and choose to investigate/join those that appeal to them. After an individual onboards, recommended guilds should be presented to them based on their interests/values.

And, of course, we need to build these things with web 3 tech. I’d suggest we want the information gathered during onboarding to be accessible by any other dapp in the ecosystem that wants it (e.g., display the guild info on a webpage like is being done now, or maybe add rich profiles to artists on Paras/Mintbase and other platforms.) Likewise, we should be building in support for things like PfP projects so people can set their NEAR avatars to NFTs.

If only there was an onboarding app that made that all possible…

Introducing My NEAR Journey

I put together this app over last couple days to help solve some of these issues and demonstrate a possible direction this could go. Try the My NEAR Journey onboarding app (testnet) (https://mynear.xyz). Recommend using it on mobile or opening dev tools and using a mobile display - still some work to do on styling for larger screens.

Will be moving it to mainnet shortly. (Note that it has some integration with mainnet dao platforms like Catalyst and Astro - those things may appear broken in the testnet version).

For those who care - it’s 100% web 3 (except that it’s currently being served from an Azure VM):

  • underlying contract deployed to dids2.vitalpointai.testnet (enabled for The Graph support)
  • react front end
  • integrated with Ceramic.Network for identity (every guild/indiv gets a DID which is registered on the dids2 contract. That makes all these profiles portable into other applications simply by accessing the did’s Ceramic data stream.
  • has a NEAR subgraph deployed to The Graph.

Any application can query The Graph subgraph to retrieve the DID of the account. Play with the example query in The Graph playground for this subgraph to see what data you can use from the registry contract.

After getting the DID for an account, you can query Ceramic and get back a guildInfo object to then display/use as you need to in your application. For example, this is what gets returned after onboarding a guild in the app (we could obviously customize the data gathered if we need something else e.g., guild operating plans/budgets):

4 Likes

This is wonderful @ALuhning, thank you very much for sharing your weekend hack with us, looking forward to testing it. We are honoured to have you on the Guilds Platform Advisory Group! I admire your particular emphasis on Guild Discoverability and already thinking about how we could work towards better geo-specific and regional connectivity for the community.

2 Likes

Hey @ALuhning some thoughts here:
We have recently been discussing with @Grace that there should be one general intake form for the individual contributors to register. Do you think it would make sense to integrate the DB of the Guilds platform with OWS Airtables DB? This way OWS we will be able to offer project opportunities to more newcomers for onboarding them. And for the Guild leaders, it will be easier to find new guild members when needed.

We can add additional questions to the form if needed, but I think it will be more efficient to merge these

1 Like

I guess that’s a fundamental question we need to consider - keep using Airtable which is a centralized web 2.0 service (albeit useful) or use something built on top of a web 3 tech like Ceramic to give people ownership of their data (part of NEAR’s mission statement) and remove the requirement for centralized administration of it (like OWS is like doing in maintaining/growing the Airtable database).

This is the issue with using Airtable - you need one general form/method to get everyone in the database and extending it requires sharing the API keys/giving edit/add permissions. If you’re using something built on a decentralized tech like Ceramic data streams, then anyone can build an interface to onboard that pertains to their specific situation and all the data that is collected becomes available to everyone in whatever form they need it. If OWS needs certain info, they simply add more fields to collect and build on the data stream - creates rich profiles for individuals that follow them anywhere they go on web 3.0. They own it and they can change/delete at will. Nobody else can mess with it - which isn’t the case with Airtable.

If you haven’t yet, I’d really recommend trying the app I put together to see how such an intake might look (it’s using Ceramic). https://mynear.xyz

If we use a decentralized solution for data streams like Ceramic, then it enables acceleration of other innovative apps.

I’m probably doing a poor job of explaining this - will work on a picture to make it more clear.

2 Likes

@ALuhning Noo, no worries, it is quite clear to me where you are heading in fact! And I like the direction. I do have to admit though that Airtables is a handy and easy tool to use for now (especially for OWS because we are using it daily to source people). But I am definitely up for exploring more transparent, decentralized alternatives once we have them fully operational. Thank you for explaining once again!

2 Likes

Amazing work, Aaron! Just had a chance to play around with it. As you rightly pointed out, some things did break for me, but what is a testnet version that doesn’t break, amirite? :slight_smile:

With a little more refinement, I think we can start using this as an alternative to the Ecosystem map, specifically for guilds. This can be baked into the onboarding process. After some more testing, when it’s ready, as @Sofia_Alum mentioned, perhaps we could even use it for individual onboarding too through the OWS. I agree with both the view points around decentralization as well as ease of use(which currently airtable helps us with). Pragmatism over perfection is in fact one of our key values.

So my suggestion here would be that the OWS team can list out the must have features that Airtable offers right now that makes your operations more efficient and Aaron can figure out which ones can we build out in the flow for individuals. Since this is a platform built from scratch, one thing to consider is that we’ll have so much more flexibility and we can build out features that are important to us, unlike Airtable. Perhaps this can also be something that the platform advisory working group takes into account- @chronear.

@ALuhning One quick challenge of all this being on chain is the tx fee every time i try to add a guild or un-register as a guild. I know the fees are negligible but we’re also trying to make it as easy and web2 like for people to join. With that in mind, do you think we can make this free(and thereby making it frictionless) by, let’s say pre-loading the contract with some NEAR to cover for the fees(ideal), or maybe refunding users immediately if they interact with a particular contract(fee refunded- less than ideal as they still have to pay first)?

2 Likes

Also, thinking out loud here, another idea that I was thinking about was in terms of the roadmap for the platform. @cloudmex-alan I know that we talked about potentially integrating mailing service at some point that guilds could use to relay important information or announcements to guild members. However, I feel like getting members back in to provide emails etc. again when we have that feature built, is going to be a huge challenge. I feel like a much quicker way of doing this might be actually building an on chain instant messenger service? Eg. Blockscan Chat - Wallet to Wallet Messaging for the Web3 Blockchain

This means that guild leads can create user groups based on their guild members wallet addresses and relay any important information. Anyone not on the platform can still login with their wallet and view the message. Perhaps this is the next feature that we can build relatively quickly and could serve as a stand alone product too, serving the broader NEAR ecosystem in case people would want to message each other and just have wallet addresses.

@ALuhning I’d love to have your feedback too.

1 Like

Hi @shreyas , I will talk to the team and we will try to prepare a list of features by next week!

3 Likes

Where would I find this?

Yes - definitely doable. I think pre-loading the contract and then creating a couple function keys for a new user when they connect (one for registering/one for unregistering) that has a set allowance (enough to cover the registration and any other actions we want them to take) would eliminate that friction. Will see if I can get it working.

Great idea. If you really want to keep it on chain though, we’ll end up with the friction of gas which I think we’re trying to avoid. Blockscan is free to chat, but the messages are sent off chain. If you want them on chain, Blockscan also has Ethereum IDM (input data messages) which are part of the input field on Eth transactions (thus, there’s a cost).

If we’re really just interested in some kind of messaging built in and it doesn’t have to be an on-chain record - then I know convo.space is doing something with cross platform comments that uses Textile.io to enable something similar. There’s also Matrix that focuses on decentralized chat. We’ve also implemented a commenting/notification system into Catalyst using Ceramic - I think it has a polling/sync capability (i.e., to periodically check for new messages) - curious now, so will look into it.

Awesome - be interesting to see what it needs to do.

Question - how were you envisioning people joining guilds through the platform? Depending on platforms they use, membership could be pulled in (is possible with Catalyst, should be possible with Astro). For those not using platforms with that kind of data, are we trying to provide them an option to join a guild through the platform (basically register an affiliation)? We envisioning an approval process by the guild owner? (or maybe a toggle that turns on an approval process or makes it open membership by default).

2 Likes

This is going to be great! Also just spoke to @Ryan.Walsh about something like this the other day about “smooth boarding” and effectively bypassing the NEAR wallet creation cost by having the devs of that platform cover it.

Ah, yes, that’s true. Could we take the blockscan approach? I also just played around with convo space, but it doesnt seem like we can create groups, or even send messages to people who arent on convo space yet- i could be wrong on this one, but i wasnt able to figure out how to do that.

I think a notify option could solve our immediate concerns actually. For instance, we were talking about having a mailing list as a way for guild leads to share important messages to their guild members. Right now, this could happen on Telegram (via pinned messages) or Discord (via an announcements/news channel). However, that might not be the most effective way and perhaps a notification option for custom messages triggered by the guild leads to their members might solve that (along with history of notifications). The goal isn’t to replace telegram/Discord by any means.

So there are two sides to this-

  • People joining the guilds platform
  • Guild leads registering their guilds on the platform

For people joining the guilds through the platform, ideally, they would either be notified in the guild onboarding process of that specific guild, to also register on the platform and be an on-chain member. Perhaps it’s a pinned message for every new member to follow. It’s easier when we have quests implemented so that we can have something like “Login with your NEAR wallet on the guilds platform, Join the guild, and complete the 3 quests for your onboarding” or something along those lines. So apart from joining the Discord/Telegram, they also join this platform on chain.

For guilds registering, I feel like there needs to be an approval process and time period- I say this because if we end up replacing the ecosystem map with the catalyst flow and use that as the database for the guilds showing up on near.org/guilds or any other lists in the future, it needs some level of control. 1 month would be ideal from guild creation time to then it being eligible to show up on the website, which means that if the guild is active for 1 month, we can approve them on the platform so that they are indexed and shows up everywhere.

1 Like

Ok, figured this out, got it working - it’s now seamless - no wallet signing needs to occur/user hits the register button and they get registered. Note: I haven’t deployed this to testnet yet.
The Graph is currently having issues with testnet indexing - they’re hoping to have it fixed early this week, then y’all can test this out. Did this by basically:

  • Have setup a funding account - funding.vitalpointai.testnet
  • Made it so the funding account is able to register/unregister/and adjust the allowance it’s allowed to spend on the registry contract. Going to be able to register several hundred of guilds/individuals for 1-2 NEAR - takes about 12 TGas/action.
  • added an admin page to the app where an app administrator can view the funding balance and top it up as needed
  • admin page also lets the administrator adjust the funding key allowance (to basically reset it once it starts running out of allowance to spend)

So, way I’m proposing to approach this, and is what I’m currently building:

  • propose we do not put any restrictions on people registering as individuals or guilds
  • when they first register, they are identified as unverified. They do not show up in any lists, but do get put on an admin list to await verification
  • on admin page, the admin(s) are able to approve people as verifiers
  • verifiers follow some process “to be determined” whereby they verify an unregistered guild is an approved guild and then mark them as such in the admin section of the app (could even issue them a “verified” NFT (although revoking it might be an issue))
  • once verified, they show up in the directory of approved guilds.
  • essentially, the verifiers ensure the level of control needed to determine when a guild becomes publicly visible as an endorsed guild

After I get this working - will tackle the notifications and a way for individuals to affiliate themselves with guilds.

2 Likes

Awesome project.

We from The Clan Guild and Brazil Guild will take a look and see how we can contribute.

@brunoqual
@whoiscavenaghi
@tesfon

We would like to be added as well, it is possible? I will see how the https://github.com/near/ecosystem/tree/main/entities works and how i can update our info.

The Clan Guild
Brazil Guild

3 Likes

Consolidated some more thoughts on guild onboarding as a pre-cursor to facilitate on-chain management here: https://vitalpoint.ai/near-guild-onboarding/

And have made some good headway on a guild’s onboarding/management application. It’s live (testnet) at https://mynear.xyz to play with, but here’s also a video run through of it describing how it works and the existing feature set. Includes beginning of a messaging capability, guild verification/tiering, gas free registration, etc…

Intro: 0:00
Guild Leader Onboarding: 3:10
App Administration: 15:10
Verifying Guilds: 21:26
Conclusion: 25:45

@shreyas @chronear

4 Likes

How is this initiative we’ve been discussing/building impacted by the reimagining of the guilds program.? @chronear

1 Like

In no major way @ALuhning I would say that we are in fact looking to expand the Guilds Platform Advisory Group’s scope of engagement by including the Platform and People into the new Guilds program as key drivers. More soon! :slight_smile:

2 Likes