Skip to content

DigiMancer3D/WaveData-HAPI

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 

Repository files navigation

Wave Data H-API

Wave Data

Wave Data is a type of Hashed-API structure for generic exporting and importing of digital objects over the internet. Export almost any webobject with as little data as possible but in a manner that can create non-static hash stored web applications. Wave Data is a dynamic API structure so any item in digital code can be exportable, purchasable, modular & of course importable. Hashed-API is capable of telling the importer what any piece of the API string is. The API can also tell the importer nothing or anywhere in between. Wave Data is one of the first Flexable, auto-expandable, informative, blindable, bindable & modular hash-based API structures. A New API structure for the decentralized world.

#lM37aD47aljl01D4742q102M374Da7A2jl02D4tA3q103nD2

Decentralizing the API is in the MARKERS!

Wave Data has rigid markers with a fluid design allowing almost anything to be used as a marker for hash mimicing data & to customize your API to give greater functionality without having to include more data points. The marker setup is like a consensus, there's a set of rules and how you follow through beyond that is up to you as long as the rules are met. There are some already established versions of some of the markers. Which pre-established version of marker sets you use may be by choice or to divide APIs for different known objects that need different reconstruction scripting.

The pre-established marker versions are as follows:

  • v1::
  • starter/closer: |
  • filler: ..
  • end: ,
  • |[metadata],..[data]..,[metadata],..[...]..,end|

  • v2::
  • starter/closer: | & =
  • filler: ,,
  • end;
  • |[metadata];,,[data],,;[metadata];,,[...],,;end=

  • v3::
  • starter/closer: | & ==
  • filler: ., & ,.
  • end: { & }
  • |[metadata]},.[data].,{[metadata]},.[...].,{end==

  • v4::
  • starter/closer: [ & ]
  • filler: _| & |_
  • end\ & /
  • [[metadata]\|_[data]_|/[metadata]\|_[...]_|/end]

  • v5::
  • starter/closer: [ & ]
  • filler: -\ & /-
  • end: | & |
  • [[metadata]|\-[data]-/|[metadata]|\-[...]-/|end]

  • v6::
  • starter/closer: ( & )
  • filler: -_
  • end: |
  • ([metadata]|-_[data]_-|[metadata]|-_[...]_-|end)

  • Blinded::
  • Bv1: Blank Metadata
  • Bv2: No Marker-end(s)
  • Bv3: Blank Metadata & No Marker-end(s)
  • Bv4: No Filler Markers



  • The Marker Rules are as follows:

  • 1) The start tag can only be repeated if it is also the last character in the string
  • 2a) The markers between metadata & data consist of 2 markers, filler marker(s) & marker-end
  • 2b) Metadata is surrounded between marker-end(s)
  • 2c) Data is surrounded by filler marker(s)
  • 3) Filler marker(s) can be duplicated or withdrawn to a minimum of 1 filler marker per marker-end (starting standard is 2 filler markers per marker end)
  • 4) Lists within data/metadata groupings should use the same marker-end marker to show divisions of data
  • 5a) end should always be used to show the end of string just before the closing marker
  • 5b) The closing marker should be one of the follow: the starting marker, the number of data groupings, a completely unique marker
  • 6) If an H-API string is within another H-API string as data or metadata, the starting and closing tag needs to be the same but completely different then all other starter & closing tags
  • 7a) If multiple H-API strings are nested together, they all need unique and seperate starter & closing tags
  • 7b) If multiple H-API strings are nested together, only the outer-most string can have different starter & closer markers



  • Marker Set, Hash!

    Once we have the data setup we can get the Base64 CRC hash of the data set. Immediately after the CRC is generated, wrap the CRC with identifiers so other importers can either be given heads-up information or know it's point of origin. The wrapping identifiers are a series of 2 serial IDs.
    The first serial ID can only contain lowercase characters and special characters that are under the half-way line or within the limits of the lowercase "u" character. This does mean, no numbers are allowed in this serial ID even if they fit wihtin the limits of the lowercase "u" character. This serial ID can be any length but must contain at least 1 non-special character.
    The second serial ID may not contain lowercase nor special characters. Only capitalized characters & numbers for this serial ID. Emojis are allowed in this serial ID, if capable of producing, for as long as they fit within the limits of the capitalized "U" character. This serial ID must contain at least 1 non-numerical & non-emoji character.
    The combined minimum length of the two serial IDs is 2 characters (non-special, non-emoji, non-numerical), with the first being within the limits of the lowercase "u" and the second being within the limits of the uppercase "U" as well as their own seperate clauses. The two serial IDs may be random or unique and the exporter of the data is responsible for determining the best way to output their API (blinded or Not, Partially or Not).
    The CRC goes after the combined identifiers then the ending is the reverse of the combined indentifiers finally capped with an ending indentifier. The ending indentifier will be placed behind any "=" or "==" that the CRC ends with. So if the CRC ends with "56=" the reversed combined indentifier combined with the ending indentifier will be placed behind the "=" to end up with "56[reversed combined indentifier][ending indentifier]=". This gives the importer enough information to remove at least the front cap (the combined indentifier) to be able to read the CRC during importing. For most cases, the ending is not needed to be removed/adjusted to be read fully but the more data within the CRC, the more risk is taken by not correcting the ending cap when importing.

    [indentifiers] + CRC - (=|==) + [indentifiers.reverse] + [ending.indentifier] + (=|==)



    Display!


    Finally, the object has been setup, hashed & wrapped and is ready for displaying so the user can take the data. This design allows for many different ways to implement the system, irrardless of what language it's coded in or just inline via HTML. This is the API structure with the people in mind. Want to add privacy, use a blinded version or create your own blinded version. Want to add files, go ahead! Want to turn it into a hashlink and sell it, okay. How you use and make use of this API is up to you. With great power comes great responsibility.

    x4PfGV4YW1wbGUsLi4xLi4sQVBJLC4udGVzdCx0ZXN0LHRlc3QuLiwsLi4nYm9vbSBjaGFrLWEtbGFrYSBCb29tIScuLixlbmR8P4xash




    You can download the .html file in this repo to experence the readme in full function over the webbrowser of your choice.

    About

    Generic standard for socket-like plug and play JavaScript/HTML elements

    Resources

    Stars

    Watchers

    Forks

    Releases

    No releases published

    Packages

     
     
     

    Contributors

    Languages