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!

[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.