Proposal to add "types" and "thing"

[elliotBraem]

I am proposing to add both "types" and "thing" to the NEAR Social standards.

These are the precursor of adding the "Type" keyword to the gateway as explained in the Social post here. The motivation is to create a data source capable of referencing anything, whether it be a real or digital asset.

The Type keyword enables developers to describe and save their own types on chain. Similar to a widget, a developer's created Types would be stored under the proposed "types" standard:

 "evrything.near": {
   "widgets": { 
        ...widgets
   },
   "types": {
       "Idea": {
           "properties": [
               {
                 "name": "title",
                 "type": "String",
                 "required": true
               },
               {
                 "name": "description",
                 "type": "md",
                 "required": false
               }
           ],
           "widgets": {
               "summary": "Everything.Summary.Idea",
               "view": "Everything.View.Idea",
               "create": "Everything.Create.Idea"
           }
       }
   }
 }

A Type contains the property schema, references to widgets necessary for creating and displaying data of this type, and optional metadata. A Type can have properties that reference other Types, allowing data to be relational.

Since a schema defines both the way data can be created and viewed, creating a Type can autogenerate code for essential Widgets. Autogenerated widgets can abstract away a lot of complexities that a developer would typically encounter in traditional development.

When data is created via a saved Type, then it will be stored on contract as a "Thing": the most basic interface for any real or digital asset. Data stored as a thing is freeform, but follows the properties and schema established in the associated Type as it is created via the autogenerated Create widget. The data saved to the Social contract looks like:

 {
   "thing": {
     "main": "[DATA]"
   },
   "index": {
     "[DOMAIN]": "{ key: \"main\", \"value\": { \"type\": \"evrything.near/type/Idea\" } })",
   },
 }

Since the Type is described on chain, the data can be stored off chain while still staying predictable. This opens opportunities for the user to choose where their data is stored and who has access to it, especially if we integrated with a decentralized storage service.

Since Types are stored under account Id's, a DAO can own a Type and its members could vote on its accepted specification.

Please consider this proposal and feel welcome to express any questions, comments, and concerns. Thank you!

[charleslavon]

hey @elliotBraem, Do you mind to elaborate on this part When a Type is created, it also autogenerates basic Widgets for creating and displaying this data. What is this process of autogenerating components?

[elliotBraem]

Hey @charleslavon ; yeah so at the time of this PR, I had methods in a revised VM that would bootstrap and commit new widgets under the type creator's account. The guiding principle was that if a Type were to be defined, then we would know the props that would be passed into a View and Summary widget, and the props necessary to initialize state in a Create Widget. I can't find the exact code, but it looked something like this:

Social.set({
      widget: {
        [`${state.typeName}.Create`]: {
          "": `State.init([INIT_STATE]);\n return (<div>[INIT_FORM]</div>);`.replace(INIT_STATE, typeToEmptyData).replace(INIT_FORM, typeToForm),
        },
  });

It was just simple string replaces for basic starter widgets that create, view, and summarize data of this Type.

Although soon after, I decided against needing to generate new widgets because it's a lot of code duplication and it means 3 new Widget paths to remember per Type. And so it evolved to a dynamic form generator like you see in the creator (which is being revamped, see post here ). I have a lot more I can share here if interested.

If you're interested in code generators however, then check out Teleport HQ's open source code generators which generate code from a JSON UIDL. They can be used to generate component code or entire projects in a variety of frameworks. We have a developer that is currently working on extending the generator for Social React; happening on the "teleport" branch here. If you're interested in contributing to this effort, you can follow this document to set yourself up with a bos-workspace and utilize a BOS -> Teleport dashboard for testing your conversions.

[gagdiez]

I feel having such generic standards goes against the idea of having a standard.

A post is a common element of any social media that anyone can understand. The same happens with a comment. Meanwhile, a type and a thing are two abstractions that represent nothing concrete, but the ability to define new things. They are meta-standards (i.e. ways to define a standard), and not standardized objects on themselves.

Because of this, I would recommend to not add them as standards. Once again, because they standardize nothing in concrete.

We already have a way to define "things" and "types": by adding standards to this repository.