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. 
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.
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.
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 
)
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:
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…
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):
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):
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.
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
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.
@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!
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?
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)?
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.
Hi @shreyas , I will talk to the team and we will try to prepare a list of features by next week!
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).
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-
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.
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:
So, way I’m proposing to approach this, and is what I’m currently building:
After I get this working - will tackle the notifications and a way for individuals to affiliate themselves with guilds.
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
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
How is this initiative we’ve been discussing/building impacted by the reimagining of the guilds program.? @chronear
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!
How is this endeavor proceeding nowadays or where can we view its progress?
I’ll speak to the progress/vision of what Vital Point AI is building - with current state on the guild onboarding app pretty much described/demonstrated above. In that reply is a link to a blog post that describes the vision and consolidates onboarding thoughts in more detail. However, I’ve got a grant and am delivering three related projects:
#1 - guild onboarding/beginning of a management platform - is live on testnet - https://mynear.xyz. The app itself takes a prospective guild leader through the process of setting up a guild account, it’s guild profile, registering that guild on chain with one click (with no gas fees for the guild leader). When setup, the guild gets its own decentralized identifier (DID) so we can now associate whatever data we want with it and consume it on as many frontends as people want to build. It’s at a point where anyone can register a guild and then NEAR Guilds program “staff” can verify it, classify it’s tier level, message all guild leaders.
#2 - Individual Onboarding - I’m currently focused on the second of the three deliverables - the individual onboarding - which has dependencies on the guild onboarding application. Called NEAR Personas, currently only avail on localhost, but I’m aiming to get it onto testnet in next day or two. It follows a similar onboarding flow as the guild leader would do, but enables individuals to create profiles that are associated with their NEAR accounts (DID issued). Last step of the onboarding provides a recommended list of guilds the individual should consider joining based on the interests, goals, skills, work desires, etc… they decide to provide during their profile construction. The app calculates a suitability score for each registered guild.
Next steps for this app include providing the mechanism for the individual to “join” the guild (register on chain) at that stage. I’m currently thinking it is a very similar (non-gas) registration method like the guild leaders use, but when joining is complete, they get directed to a location of the guild’s choosing to continue the guild specific onboarding that guild has setup for their new recruits. That location will be defined in the guild leader’s guild’s profile.
#3 - is a proof of concept that will demonstrate how anyone can use the backend registry and functionality built into #1/#2 to have their own guild branded onboarding flows setup for their guild. I’ve gathered enough info on the specifics of how OWS operates to produce this - will be next up once the backend pieces are in place.
I’ve created frontends for the guild/individual onboarding to demonstrate functionality - but, of course, it’s all composable - so more talented designers/frontend UX people can build on what we’re providing.
I think the quickest win here/what I’d recommend trying to achieve in the very near term is getting the guilds onboarding application on mainnet (after some testing) and using it to replace the current Github ecosystem repository that provides the data for the various sites that use it. Main benefit being the much more intuitive/ease for non-developer guild leaders to update their guild data. It’s very easy for a frontend to query the Ceramic network for a DID to get the guild’s information if they are registered. Here’s a sample data object for a fictional guild currently registered in the app. Of course, we can extend the data model to collect more info as needed, and the data belongs to the guild leader - only they can change it (and it changes everywhere it’s used):
Happy to receive feedback/answer questions/give demos/continue the discussion in bringing all this to life. Would be great to get some guild leaders trying it out - https://mynear.xyz
