EntityScript™

OpenPackager™

---

OPENPACKAGER™ is a way for your system to use any extension program without installing them into your main machine. Similar to containers, yet unique in various ways because each container requires a checksum verification to initialize.

You're able to Tie real (as in a program with functionality) and fictitious entities (as in a EntityScript™ template designed by an operator) to enforced context modules that utilize the .entity to .ds relationship. These modules can installed in a special location that will then enforce verification that the version in use is the one you're intending to use, and not one that has been altered somehow during download or setup. If it's not verified, it won't start. OpenPackager™ keeps tracks of active versions key-hashes and then enforces those hashes before runtime.

Using OpenPackager™

A variety of different environment choices can be made within your system. Each system will have some sort of kernel and some sort of boot-related program that links the system hardware to the software of the Operating System.

It is recommended that you use the smallest possible blueprint for the kernel and the hardware initializer sub-system. You should follow up on this methodology by being conservative while implementing any additional system-level packages. It is even recommended that you use some sort of security module to make sure a program doesn't have scope or access to system resources it shouldn't have access too. Some popular ones are SELinux and AppArmor.

System-level packages should only be installed from trusted publishers. Trusted publishers are not random open source developers. Although their code may be cool or useful, these programs should be installed in OpenPackager™ and not at the system level. If the publisher isn't trusted (although they themselves may be trusted as a person and have integrity- the software may not be vetted to the standard of 'safe to use in production'. 'Safe' is subjective, but objective criteria can be used when determining if something is safe for system-level installation or not). It is important all packages at the system-level conform to some higher standard of system security. This usually means these programs are open-code, even if they're not open to modification by a specific vendor. These practices can be enhanced more by adding additional middle-layer control packages and saving user-space packages for OpenPackager™

OpenPackager™ extends trusted programs into a clear user-space package control framework. This framework can terminate these packages while in use without modifying the state of the C.ORE™ program - and each OpenPackager™ runtime is a second-order program inside of C.ORE™. EntityScript™ provides templates to enforce the proper controls of added packages, both at the system-level and at the user-space level through OpenPackager™.

OpenPackager™ favors programs being extended with additional meta-class related behavior that themselves run as single use processes. Blobs are considered poorly designed if specific threads can't be inspected with the default audit framework provided by EntityScript™.

To search for new packages, OpenPackager™ uses CORE.HOST™ to retrieve, install, and manage external package checksums using something called a VCNKEY™. A VCNKEY™ is a multi-purposes block-generated token that can act as part of 3 part verification system to run packages in a more secure fashion. The other two parts aren't covered by EntityScript™ because they're handled by a program called TRINE™ - something that communicates directly with any block-related program and stores both the public-key of a block transaction and the user-party associated with that key. TRINE™ then acts as the endpoint where you can contribute your credentials to verify that you're able to interact with the 'universe' you're querying.

Your system may use your own distributed and controlled branch locations even if they haven't been made available to the public through CORE.HOST™. OpenPackager™ also uses private locations to retrieve system level packages trhough some kind of virtual environment. If a program is not in a virtual environment, it won't run with a valid checksum. A program with a faulty checksum is not able to be accessed by C.ORE™.

---

CORE.HOST™ was designed specifically to distribute and provide access to OpenPackager™ compliant entities.

More programming languages can be used besides the one chosen to implement EntityScript™ (Python) but they'll be expected to hold true to various established conventions.

When distributing packages, the operator takes responsibility about how this software interacts with both the graphical system and the underlying sub-system. Some code doesn't require UI features, but other programs do. All UI systems are implemented indepently of other UI systems, so it is preferred that UI components that are in use are of a somewhat universal standard or type. For Linux, something that is X-based will always work okay.

Additional code that's added to kernel itself doesn't rely on the same checksum process, but the behavior falls back to the kernel-level program management ecosystem in place. EntityScript™ and C.ORE™ do not determine what is a valid system-level program and what isn't. They do however determine what is a valid system-to-user-space hook for additional program behavior. The sub-system that does this takes you all the way into the metal with a software-layer and OpenPackager™ makes sure some basic details are in line before it'll allow your system to allow for that kind of program to run.

The following conventions for OpenPackager™ are relevant to this methodology:

Location: .CORE/OPENPACKAGER/

There are two preset environments for this established convention. The first is corehost and the second is external

Whenever programs in these locations make system calls, they should also have some sort of logging mechanism attached through the audit framework. Activity from each of these program can either be generalized in the activity logger, or made specific through the installation of thread-specific logging on specific program behavior.

These two locations can be used by other programs of various types to access certain supplied system resources, such as RAM, DISK, BUS, or GRAPHICS. The programs that use these locations then are provided a set or unlimted amount of those resources.

Altering enforcement mechanisms to allocate system-resources can happen through the RING/ section and can be done through a .ini file or similar. See core_interface to learn more about extending system level functionality.

Since these locations link to the RING and the RING enforces what programs can and can't do, the RING should not be altered. The same would apply for distributing or redistributing these types of files as well - they aren't meant to be modified by the community, yet - they're meant to be elevated to a community standard that's acceptable for the desired program purposes. You define the program behavior and the logging verbosity yourself later, and there won't be a clear standard about what is the best way to do that. It'll be part art, part science.

An operator can determine how to tie thread-logging and activity logging into the RING properly - a place that won't change but provides enforcement of system resource allocation. To summarize, the RING will control various parts of ENTITYSCRIPT™ resource allocation contexts. These resource contexts are for accessing system resources within C.ORE™ and can be set on a limited or unlimited basis. The RING will also determine if those resources can carry anything towards the network for sharing or not and also determine if a OpenPackager™ program can have resoruces allocated to it or not. What people share on CORE.HOST™ is usually just an .entity file. But by participating in certain activity with CORE.HOST™ you also may generate a public record. Public records are either masked (private) or public by default.

---

All .entity files are stored according to the following conventions:

Collected software: additional items of interest that can be run as a system extension within the IPDVC™ by utilizing OpenPackager™.

All .entity files are the root context-map provider to a package. Each type of traditional system can be extended with these packages and made into an entity-extension systems. Systems that start out enabled for this type of system-behavior are called entity-centric systems. These entity-centric systems are sourced either locally or are made available globally. Data within these systems isn't shared by default, but the configurations of the systems can be made available for resuse to the community or additional computers that you operate.

The default handlers for these files are written in Python. Python helps the middle-layer make system calls as OpenPackager™ functions making runtime decisions. Python is used as the implementation layer for the underlying system services in OpenPackager™ too, but it doesn't make others rely on it or any specific language because any code can run through an extension enforced by OpenPackager™ and the appropriate EntityScript™ template. System services utilize the Access Identity Ring (AIR) platform can be used as an acceptable additional system constructs and extended to any user-space functionality after the fact.

The .ds data sheet DATA SLUG file type takes on comma separated cell usage in the most basic form, with constant quotes and headings enforced. Or these files takes a general 'blob' formats of any type but must then be hooked to an appropriate processing template in EntityScript™. Any format is supported with the appropriate parser being hooked to the blob.

There are index and key-based rows that can activate traditional column-based lookups for data. This data can be fed-to OpenPackager™ linked programs through the airEP™.

If you extend the base system lookup routines using core_gather the discovery and search for custom data-retrieval is also possible. You can use this to store a list of the packages that are in use and also use it for any other desired user-space lookup formats as well. A .entity file defines the title, the middle-layer package index headers for the corresponding .ds files, and any additional modifications or add-on file extensions.

That's it.

---

OPENPACKAGER™: Extensions

Right now, the only supported external extensions are:

Jupyter Notebook https://jupyter.org

The notebook should be accessed through a separate virtual environment and through a standardized https only approach. This requires some additional setup. Follow the following convention of placing the notebook system in a unique and separate ORE file elsewhere before you begin.

pandas https://pandas.pydata.org/

core_gather utilizes pandas when the operator chooses to do so. It makes things much more capable on the data science and data-framing end. Check out the project.

These are two examples, but any package can be utilized to increae the program functionality.

---

OpenPackager™ Entity Creator Questions

You can run the core_creator like this:

This will return an interactive prompt that can be used for .entity creation and setup functions. There is also a graphical interface feature, but the default is just a plain text adding system.

Entity Creator Questions:

Note*: If everything worked you'll see the following message, or something similar in structure:

The following .entity file was generated and now resides in *PATH*/DS7746875.entity

Now that this .entity exists, it is an index and meta-information portal to the rest of the system. It can be called by performing a lookup to the file using the lookup mechanism.

There are 5 starting types of Entities to create. These entity types are: Alias, Entity (Standard Context-index), Figments, Humans, and Locations. More can be defined too, but these are the intial 5.

All 5 of these types can either be a indexer, a contact, or a game. A game is an abstract-method that handles any defined-context. A game isn't like a sport match or casino, it's meant as an abstract method, like as in a 'game theory' implementation of any type with behavior that is understood through a control matrix-only. All the types have different extensible features that are attached to them depending on what is chosen during .entity creation. Some are static templates to provide static information, while others have time-based parts and can be used as part of an activity-based task.

---

.entity file example

# DS7746875.ds - KEY::: 'fuuid' # Entity Snapshot datascript_id = ['fuuid'] title = ['Fun People'] # Package Snapshot package_type = ['indexer'] package_id = ['CVF67I89MJ4EA'] # Directory List-file DLIST = ['DS7746875.ds'] # Index-List INDEX = ["id", "fuuid", "fun-name"] # Identifier Overview<br> identifier_type = [ ("id", INT), ("fuuid", CHAR), ("fun-name", VARCHAR) ] # Datascript Module Context<br> datascript_module = [<br> ("fun-name", "FUN PERSON NAME", "Who is this fun person?") ] # INCLUDE - Additional modules that were included<br> include_module = [ ('DS1827293.ds', IMPORT_BY_LINKER( 'DS1827293.linker')) ]

---

The previous .entity file will be human and machine readable in C.ORE™ and provides a variety of meta-linking attributes based on the fields provided and the linked-files. Togther these form a structured entity-based DATA SLUG. A Data Slug can be used in an automation routine or reused later as a database-type of middlelayer..

---

Additional terms are used in the documentation (Partial-list: Full list with version 1.3)

Known Defense Schema

A file system where the position of the files and the duties they have remain known to the access-control program. This is done by designating the behavior of the program into various meta-functions and then using the allowed functionality to define to the access-control logic to system-resources. No system-resources are allocated directly.

System resources are allocated according to defined setup modules and security measures are in place to obscure these files from the view of any OpenPackaget™ user-space program.

Their byte size and inode position remains hidden to other system programs and the operator unless they're accessed though specific kernel-derived programs specific to making safe-lookups. This is similar to how the passord and shadow files work on Linux, but also implemented in a somewhat unique way.

A Known Defense Schema is built to be compliant with various authorities too. In some computing scenarios the required access logs can be generated and stored by default. If the IPDVC™ was in use at a health care organization, HIPAA would require certain information to remain private. You could put that information behind a hook and only have the location of that be revealed through an activity-que that in logged by default with certain parameters. There are also additional methods for providing ways of hiding data from unauthorized operators. In the event this data-trail needs to be revealed to an authority for compliance, it can easily be made available without needing to implement additional database voodoo.

Protected EntityScript™ words: Strings that require an escape of ###/(YOUR_ESCAPE_HERE)

These escapes can be used inside of a .entity file so that it can display machine-significant keys in human readable context locations while remaining compliant in text-mode. An example would be if you tried to use a protected word in the 'datascript_module' section it would throw a silent error, although no alert is made. Upon an automated check these errors can become discoverable and are able to be fixed by replacing the protected words with the replacement text escape strings.

These protected strings are not able to be used outside of the default positions in .entity files. They are only significant in specific locations. If they present a collision of protected strings in the protected key-section, a silent error is thrown and only discoverable upon a system-based check of each file. This is the intended behavior.

---

Publishing to CORE.HOST™

https://CORE.HOST can be published to as if it were a feed retrival mechanism. These feeds can then be propagated to networks that rely on the feed endpoint. If you have a VCNKEY™ that's valid, a authentication device check is completed without the users input. If you don't, authentication credentials will need to be provided as if it were an API. You can use your valid VCNKEY™ for generating contenxt according to a specific EntityScript™ defined block-storage context. Even a specific community that you create on CORE.HOST™ can be defined by EntityScript™. If that community relies on software, everyone will install it using OpenPackager™ therefor when they interact with the server all of their behavior only is generated from a containerized version that can provide default functionality. This enforces a specific type of data that's able to leave one machine and travel to the server or to a peer.

Although CORE.HOST™ is featured as an endpoint vetting system, many other types of block-storage systems may be accessed or used as an extended drop zone for your data - or a pickup zone for someone elses data. If someone else follows this exact convention for their endpoint and access-system using entities, there is no reason another server couldn't be used to do this as well.

Default stores of value can be made general through the following standardized exchange format:

*NOTE: These units have no defined value but adhere to a defined system of programmatic exchange.

The system has 5 properties: 1.) ItemVisualIdentity 2.) UnitName 3.) ByRarity 4.) ConversionMap 5.) CoreUnitDescription

In testing, the following table was defined and is accessible within core_transmitter as the example framework. It includes server-time based standardized unit distributions to members and the defined conversions of each unit.

Unit transfers are also possible, as is providing protection of locations based on available member-owned units.

Each unit-based mechanism for reclaiming unposted Unit transactions is theory-based for now, but there is a prototype that allows for the functioning of this concept. These scripts can be built on and altered to define units and values of your choice too if you're hosting a specific endpoing, but they're based on the overall unit value system. You define by Rarity, function, time, and purpose.

The default theory peg is "DGOLD-X" a mock digital store of value to use during testing.

When any resource is made available to exchange types, it's also recorded on three sub-tables. Here is an example of what each of the 3 sub-tables look like.

1.) Value-table, general:

---

2.) Public Domains accepting ORE™:

---

3.) Private Domains accepting ORE™:

---

---

Together, this type of system creates value exchange options in C.ORE™ utilzing CORE.HOST™ or a system like it. 'ORE' is the default exchange type base-value, although it is valueless as a currency. It does hold value as a store of activity-based time-value. ORE stands for Operations Resource Enclave™ and ORE™ has significant properties in EntityScript™. ORE™ provides a way to exchange meta-information of various types utilizing this base-format.

The following set of publishing tools makes up the entirety of this posting, editing, access-control, and data-removal system. core_url and core_transmitter work together to format these requests on the fly, including validation according to the below format details.

Block device ledger: Standard .entity retrieval mechanism from an ordered and compliant index

'index-slug' is setup to also take keys. Keys are created by others in C.ORE™ or adhere to a prebuilt kind. For instance, 'L:' at the beginning of index-slug declares a readable and compliant list location.

'index-slug' can also be either openly named, or masked through a special property called 'MASKED ENTITY'. When a masked-entity is created the default master-copy location is 'MASKED RECORD', while the default 'record-location' value will be set to 'UNAVAILABLE RECORD'.

Each of these hidden record types aren't set up to follow any specific position in this example, but a position does exist. While an access-point is live, three distinct locations become available once activated. The first is a 'index-slug' location, storing the resource location of the LINKED_OBJECT. The second linked-to position is the 'master-copy'. A master-copy is a direct link to the stored location on a compliant block-exchange structure. Lastly, the 'record-location' provides a unified resource point that stores meta-data about the linked-entity.

Together, these actions store the meta-information on a ledger and become an available resource that can evolve without human input.

FinalLedger

With these ledger types now available, records can be determined 'ONLINE' or 'OFF' making them either discoverable to those with resource access or they will not be available if they're 'OFF'. Next, the default record values of each entry will generate into a posted and compliant block-storage structure according to this format. Here is a look at the default record-store.

Example:

---

C.ORE™ Record - DS3927107

---

---

FinalIndex: General mass-access location

---

A final index is now made available. Here is an entire FinalIndex example.

---

C.ORE™ - FinalIndex

---

To summarize, OpenPackager™ gives the operator various forms of open information exchange formats to utilize for various tasks, from packaging to meta-information, to transaction unit-protected methods.

---

To see an extended list of special locations in C.ORE™, click HERE