In mid-June 2020, I joined the NEAR Guild Program. NEAR Guilds take many forms but in essence, they are communities supporting the NEAR ecosystem in some way. My guild is Vital Point Guild and it's objective is to help people learn to develop using NEAR protocol by focusing on building and releasing projects for real world issues.
Once accepted, guild leaders become part of the NEAR guild community and are provided with a community platform to interact, share ideas and ask questions. We are rewarded with platform tokens for one off bounty and routine regular engagement which will eventually be exchangeable for NEAR tokens.
More...
It's up to us what we do with the tokens, but I believe the majority of us will be investing them back into our guilds, rewarding our own members for their contributions to help build out the ecosystem.
Rise of an Idea
Tribe - cloud based community platform
The community platform currently used by NEAR for leader guild engagement portal is Tribe - a cloud based solution. It's white-label meaning it can be branded to an organization's needs and hosts a wide array of features focused on creating lively and engaging communities. Of note, it incorporates a community token that can be distributed to an organization's members.
On joining the guild program and accessing the portal, I immediately thought it kind of odd that a layer 1 blockchain protocol like NEAR intent on ushering in a Web 3.0 world with decentralization uses Web 2.0 tools to build its communities.
I know Web 2.0 and Web 3.0 can co-exist nicely, but given the speed of NEAR transactions and inexpensive gas usage, it seemed very possible that one could build a decentralized community platform with the same gamification and engagement features as Tribe directly on NEAR. The one thing I wasn't too sure on was how to store all the data associated with such an application - so I stopped thinking about it and carried on with other things.
Until...
Along Comes EthGlobal and HackFS
A few weeks later - mid July 2020 - I found out about HackFS - an Eth Global Hackathon. Having competed in two previous EthGlobal events - both outstanding - I was immediately interested in the focus of this event - IPFS, Filecoin and decentralized storage.
Taking a look at the participating sponsors, I learned about Textile.io and suddenly saw the very real possibility of integrating NEAR with Textile, thus solving my storage dilemma, to create a decentralized social media community platform native to NEAR - potentially even as a future replacement to Tribe and other centralized community platform offerings.
At very least, I reasoned that even if nobody else turns out to be interested in such a product - I wanted it built for my guild - Vital Point Guild. Investing the time and effort into building such a decentralized community platform on NEAR complete with NEAR wallet/token integration serves a couple purposes:
- provides basis of a real world project for our upcoming VP Guild Academy that I will use to teach new NEAR based developers how to tackle real-world issues;
- provides my guild with a platform that is completely customizable and not limited to a set of features inherent in existing platforms;
- gives everyone using it ownership of any data provided - they can leave it, delete it, or move it at will;
- provides community components that will be useful to integrate into other products I'm building such as Paralog; and
- while not Ethereum based - provided a great project to work on for the HackFS hackathon given the decentralized storage nature of the application.
Sidenote...
in my opinion, hackathons are awesome events to level-up your development and blockchain skills. You get introduced to new technologies, access the experts/mentors, and generally just come out the other end so much better and further ahead than when you went in...
Of course I signed up...
It was a no-brainer and and I have spent the majority of my free time over the last month building out my vision. As these things usually go - what I've got after 30 days of part-time work isn't even half of what I envisioned and hoped to achieve 30 days ago.
Things happen, life gets in the way and the tech you're building on constantly changes (testnet timeouts and well intentioned api/sdk updates consume hours of your life to track down new issues and update code that you just managed to get working - sarcasm intended ).
Despite the challenges, I'm super happy with the learning that happened and even though it's not anywhere near perfect or production ready, it's a fantastic start and proves that a decentralized community platform built on NEAR and Textile (IPFS) is both doable and useable.
Whether it's enough to win any HackFS prizes is another story altogether...guess we'll find out in a week or so, but given the quality of talent, the teams, and projects that come out of EthGlobal hackathons - won't be placing any bets on myself. Some extremely talented folks out there. I just count myself lucky to be able to glean bits and pieces of their intelligence here and there.
Here's My HackFS Submission
Part of the HackFS judging is a 4 min video detailing the project to be followed up with a 3-4 minute Q&A session. I can tell you it is super hard to get a project you've spent 30 days working on into a 4 min backgrounder and demo.
Word of Advice...
if you're in a hackathon needing a video, leave a couple days to get it together - took a lot longer than expected.
There is a live VP Guilds demo available - deployed on Fleek (which is also extremely cool, super easy to use and a great alternative to things like Netlify if you want to deploy to IPFS). Fleek also uses Textile - definitely recommend considering them for your future projects.
So, how did I build it?
You may have been following another post I wrote recently regarding using NEAR accounts as identities for Textile. Central to my whole plan was linking NEAR accounts to Textile threadsDB threadIds. If you're not familiar with Textile - think of it as a database provider. You can run your own on your hardware or use their hub - which I've opted to do for the hackathon. In future, I understand it's trivial to leave the hub and run everything through my own instances if so desired.
Step 1: Associate NEAR accounts to Textile ThreadIDs
First thing I needed to do was use a NEAR account to authenticate against Textile to link a database (threadId and identity) to the NEAR account. Like the NEAR wallet does now, the Dapp stores that important info in browser local storage and queries an authentication server to get a token that allows the user to interact with their Textile user database (thread).
Textile allows both user and app level databases (threads) to be created. User level threads mean data put there is only available to the user whereas app level threads are created with an account key that makes any data in those threads available to the whole app. From a decentralized community standpoint, this is important because I wanted users to have the option of determining exactly what info they shared with everyone vs what they keep private for themselves. I'll come back to that in a minute.
Step 2: Make sure nobody loses their data
Storing things in browser local storage works fine until that storage gets cleared - then the user loses access to their data forever - not good. To get around that, I not only store the identity and threadId in browser local storage, but I get an encryption key from the authentication server and encrypt and store the textile identity and threadId in PersistentMaps on NEAR.
As an aside...
It was never my intention to stand-up an authentication server to provide that encryption key. I spent many, many hours trying to figure out how to prove identity using some kind of signing in a way that I could use that as the encryption mechanism - never quite got there and had to move on... Probably revisit at some point.
Thus, when a user revisits the Dapp, we first search their local cache for an identity. If not there, we query the NEAR chain for it. If it still does not exist - it's either because it's the first time the user has used the app or I've blown away the old contract and updated it (of course, that won't happen when it's live and the keys are removed). At any rate, the identity is retrieved and local storage is restored so the Dapp can function properly.
Step 3: Start making the community platform useful
With the identity, linkage to NEAR account, and authentication sign in/sign out stuff sorted out - let's turn our attention to the Dapp features itself.
Right now, it's pretty underwhelming - simply manages user profiles, allows pers to create and submit news or posts, comment on, edit, update, and/or delete those posts, see lists of all users, and see their current NEAR wallet balance. Nothing earth-shattering, but the cool thing is that it's all done on IPFS through Textile and the functionality all comes from the NEAR contract powering it.
The profiles is something I'll definitely be coming back to in the future. See that as a standalone composable component that could be built out for NEAR in much the same way 3Box does for Ethereum.
Managing data accessibility
I mentioned earlier that I wanted to ensure that people have a way to keep their data private or publish it for the dapp to aggregate and display. I've done that by creating an app level database and individual user databases (threads in Textile speak).
If a user writes a post and toggles it to publish, it gets saved in both the user and app databases. If they subsequently mark it as unpublished or delete it, the app and user databases get updated accordingly. Doing these gives the dapp the ability to track published and draft posts per user. I believe Textile is working on more fine-grained access control which might supplant this design in future - but that's how I've got it working now.
Link to data off chain - unique IDs to IPFS through Textile
I'm currently using the NEAR chain to store hash ids to their respective post data, comment data, profile data and so on on IPFS through the Textile hub. Pretty sure that's normal for most blockchain apps and by doing so, I limit what is getting stored on chain to the tombstone/important info.
Data integrity...
The Dapp currently generates a verification hash for any data that gets posted. Why I built this in - I'm not 100% sure. I think I intend to use it in future to verify that info is in the original state it was provided when recalled from IPFS via Textile. Not really sure I even need to bother with this as I believe IPFS CIDs naturally ensure the content hasn't changed (otherwise the CID would have changed...). Regardless, it's currently baked in - not doing much, but it's there.
Textile threads refer to collections which are basically database table schemas. I build one for each type of data the Dapp needs to keep track off and they're linked together via ids just like any relational database would work. The Dapp currently has collections for user profiles, comments, news posts, categories, and so on... all the typical stuff you'd find in a WordPress installation.
Step 4: Deploy it and start getting feedback
I chose to deploy on Fleek and was incredibly, pleasantly surprised. Pretty much identical to what you can do on Netlify, but it puts everything on IPFS. Took about 10 min to learn the platform and get the app up and functioning. How is that not the future of hosting?
In Closing
Because HackFS is an EthGlobal hackathon, I want to quickly address why I didn’t choose to build this on Ethereum.
While Eth 2.0 may change the equation, in my opinion it is unreasonable to believe that people will choose a community platform that doesn’t offer the same general performance at the same general price point as existing centralized platforms. Ethereum simply costs too much and takes too long to be useful for the community platform I envision without using a layer 2 solution.
When HackFS launched, I was just becoming familiar with NEAR protocol and thought it was a great opportunity to explore it more in depth. NEAR is now what Eth 2.0 may be able to achieve in the future. It’s fast and cheap and has some other features that I believe are essential to adoption of any decentralized social media type of application.
Even though I’m building this on NEAR – there is an Eth/NEAR bridge which was part of my original vision - just wasn't able to get it implemented by submission time. I think everyone benefits when everything works together.
Would love to hear what you think - leave a comment/feedback. Until next time, happy developing/building/blockchaining or whatever you do.
