Special File Key-types
The following Keys can be used in C.ORE™ and each are able to be tied to available to EntityScript™ pre-built templates. To activate various system locations and make them discoverable for a variety of context-specific functions, you can follow certain defined key-conventions or create your own.
Part 1: SPECIAL KEYS -> abstract processes within the system that are able to be standardized into control-structures: An abstract process is anything that's defined by the machine without a clearly set identity in a traditional cell-based data-format like what's made available in JSON, CSV, and XML. A routine or type-check becomes necessary without having full knowledge of the digital material being processed. Some of those processes can be summarized by the following keys:
Note*: These Keys should be used inside of a separate ORE/ folder of your choosing. Usually the ORE/ location exists outside of the default .CORE/* location. It's recommended that the ORE/ location of your choosing be on an exteneral drive that has an automated backup routine attached to it. ORE/* takes on the form of XA* conventions because it's considered compliant data even if it houses 'raw' files of the unstructured data-type. The default convention is to name 1 folder inside of 1 ORE/ location something random and set the special keys up. These Key folders can be instance wide, or ORE-based: as in only 1 ORE/XA* directory at a time to deal with on the fly data-processing of undefined types.
ORE and EntityScrtip™ doesn't know what the data means, only that something unknown is being processed. The goal is to use special keys to get to a type checked component established in each compliant area for future I/O resources that are added to the structure. You may have to go through these folders occasionally and process the data manually - but the goal is to automate the processing beforehand by having a more strict definition of the stored-data structure and the future types that are added to it. This area can allow for strict or casual policy enforcement too based off of these special abstract Keys. They are:
AAA_
Any topics and information that you didn't generate yourself should be located with this Key at the beginning.
This Key should be broken down by meta-topic, meaning - the overarching topic should be the first location, followed by each meta-class under that.
It's recommended that you use this Key inside of the FILTER/ section only and move specific file types into a .ds/.entity relationship later.
For longer term "public media" it's better to either symlink to a ORE/ meta-bucket from a filter, or to some other external masked unit-based-pipe. It's not good practice to host these types of files on your main system itself ever if you don't have to.
RRR_
This Key is a special instance called the Random Resource Recovery.
Any old, past, incomplete, or broken archives that never reached a finished status can be located more safely in one of these files. They're muted by default and on Unix-like systems they have permissions enforced to a security friendly methodology. C.ORE™ will eventually be setup to scan these folders according to your security/malware policy setup elsewhere. If you're doing a recovery, it can start in one of these key-destinations.
You may also create recovery folders for individual documents and either fully or partially complete archives. These folders are capable of holding forensics-grade recovery tool output.
It's better to symlink to a ORE/ meta-file than to host these kinds of files directly on your main system.
ZZZ_
Any library or script that isn't current or doesn't fit the current specifications enforced by your IPDVC™ goes here.
A general recommendation: it's better to symlink to a ORE/ meta-file than to host abstract processes on the main system.
This is often thought of as the "legacy" branch or the "deprecated" branch of your data. It can store either media/functional file types and may signify a general lack of order of the structures contents. In C.ORE™ it's looked down upon to have a file of many random unreleated files.
z_
This represents a archive that has been highlighted as incomplete and ready for immediate elimination. You can also use this to signify a structure as being a work in progress and needing attention in the shorter-term. The folders contents should eventually be either a full process or archived elsewhere. If they aren't ready for archiving and won't be, they should be purged. Anything that isn't finished yet that's important should have a z_ prepending it really. You can set CORE.HOST™ to not track these in various special types and for various automation routines they're able to be excluded entirely.
Part 2: SPECIAL KEYS -> Program defined or explicitly structured processes
Note* These Keys are used to make something discoverable to the IPDVC™ and are meant to be reused again. They include values of significance and can be located inside of the MEDIA/ multi-part structure or custom linked to discoverable directories within ORE/*.
A.) Storage Keys
XA_
This Key is used to signify a compliant storage structure but one that hasn't been certified as archive ready.
XAA_
This Key is used to signify a compliant storage structure and also one that has been reviewed either by a machine or human and certified as archive ready.
B.) Operations Keys
DS
Use DS before any file to make it discoverable to the datascript_id module, thus allowing it to express itself as a datasheet DATA SLUG connector of some kind, which will make it linkable to a desired .entity
LL
LockerLink™ Keys are standard connector objects that archive locations and endpoints to descriptive or qualitative text. They're discoverable to programs within C.ORE™ that use networks or category tagging to function.
LLB
LockerLink™-> BrowseMeh™ Keys are standard media retrieval mechanisms that are able to be discovered and processed by the BrowseMeh™ visual display engine. These links are also able to be broadcast as a sequential image library that plays through the module RemindMe™
ESO
EntityScript™ ORE Keys are used to retrieve, edit, and delete ORE/ locations.
ESV
EntityScript™ Visual Keys are used to retrieve, edit, and delete VISUAL/ locations that handle media files of specified types.
PK
People Keys are used to store locations having to do with someone that you know. They can be used as reminders for birthdays and showing you memories.
Part 3: SPECIAL KEYS -> Protected
Note* These Keys have special attributes and can be used as something called a 'active qualifier'. An 'active qualifier' makes sure something is happening according to a supplied definition before including the resource in an automation routine and completing the computing task without human input.
Protected:
A.) Special File types
When you're running a large system it's important that files of the wrong type don't end up places they're not suppose to be. They also can't have permissions that could under a variety of situations cause harm to external systems through contagious processes. The machine being used at the time is important, but all linked machines are also important when they're communicating in real-time. You want to make sure certain processes don't link into the host system ever, therefore most protected systems should by default be isolated. Really, we need to be blocking certain types of forms and functions from linking to the host machine ever because it keeps the host machine secure. This is a classic "escape" paradox from a system administrator point of view and it's addressed by Special File Types (SFT). They are addressed by structure first and form later here. Some are excluded because of the type of content they hold, even though this content might not pose a security risk.
Don't copy anything into a folder blindly that has any sort of significance outside of a Special File type to handle this type of data-type.
Adding a generic web filter
Sometimes people have personal information in random places and rules are needed to identify that information and remove it. By making sure that anything outside the machine can't come in and if it does it goes into a specific location, we're certifying this can hold up overtime by addressing certain common content-types from the start. In terms of web browsing, anything taken in from that device vector should go into a set convention to be destroyed later or isolated from the system as much as possible until stored in a compliant structure.
Take this into consideration when loading in modules or installing extra software from populatr software hosting sites - just because something is hosted in the cloud for you to download and run doesn't make it a good idea. You need to be aware that not understanding the FULL range of permission implications on the base system could easily make many assumptions being made wrong. This happens with other items on the network and so on.
Also, |_| doesn't work right on many OS path resolvers. This then can be used to create special behaviors as a re-linker because of this - where the initial *PATH* doesn't work in a variety of modes. The hook for meta-files with different attributes is |_|. You can put immutable objects or other special functioning processes inside of them with less worry of alteration as an additional security enchancement. Overall, many file types can go into these filters too if they're considered potentially harmful - so it has two functions, security first and added security. These are made available to mitigate attacks to your machine, not stop them. They are designed to act as mini-micro-kernels for the path finder in C.ORE™. They then can run together in static "universe" files that only knows how to talk to other filters. These files follow these conventions:
In each instance
< OPTIONAL_SYM_LINK > is replaced with the relevant value.
Location: .CORE/FILTER/
There are three main basic filters to help with local enforcement of the above ideas.
Location 1: < OPTIONAL_SYM_LINK > |_|FILTER_+\
ADULT_CONTENT_+\
DECIDER
Location 2: < OPTIONAL_SYM_LINK > |_|FILTER_+\
COMMUNICATION_RULES
Location 3: < OPTIONAL_SYM_LINK > |_|FILTER_+\
MACHINES
The following is the basic FILTER activation.
|_|FILTER_
As a convention, this always prepends or presents at the beginning of a location that's activating the filter.
Additional Protected locations:
These locations can store single state or single-purpose virtual machines.
|_|FILTER_+\
MACHINES contains other peoples stuff, mainly for reference on various topics or materials. You can use this as an assembly bin for compiling new combined works. This folder doesn't bundle with any of your creations. Your creations get shared through an entirely different sub system in the IDENTITY/ folder.
|_|FILTER_+\
COMMUNICATION_RULES contain virtual-sharing system rules. They can assemble torrents, allow webcam or microphone, allow network access, or decide if paths to other "end-nodes" are allowed. An end-node would be something that receives some I/O connection and sends back a formatted response. This rule set also allows for you to map the way your system speaks to the world to EntityScript™ rulesets. It allows for either direct discovery or connection to processes that may or may not use the network utilizing various proxies.
|_|FILTER_+\
ADULT_CONTENT_+\
DECIDER contains basic definitions for blocking adult content and disabling various features in a family-setting. Defaults to block.
Extending the metal
Part 4: SPECIAL KEYS -> System Keys
.dugout files
Your .dugout/run_program.dugout file must define some additional variables to get program extensions working at startup.
Here is an example utilizing *Details coming Version 1.3* and a *(Details coming Version 1.1)* environment, a pretty common setup.
1. You need to post the full path to the ORE/ directory setup elsewhere that holds your virtual *(Details coming Version 1.3)* environment and name it something, like 'JUP_DIR'. Certain configurations will need to be accessed and changed to exist in this location, but if that's done, you can keep adding more and more ORE/ files for different activity. So, instead of then running these programs directly on the machine, you run it virtualized in the IPDVC™. So to continue with this example:
entry: JUP_DIR=/run/.../ORE/XA**47/
Now, in ACCESS/ you can generate new definitions locating each needed file type>
2. You need to setup a macro to get the program running at startup or tie a start function to it using a setup script. This will make it accessible to active qualifiers that will run it in the right way. Name the routine something simple, like 'jup'
entry: alias jup='cd $JUP_DIR;source jps-env/bin/***; *RUN/START COMMAND COMING IN Version 1.1* --cer*****=
~/PROTECTION/jupcert.*** --ke*****=
~/PROTECTION/jupkey.***;'
3. To activate it, simply run:
$ jup
Or, you can just tie these routines to a setup script or other already-existing routine.
You'll have to self generate the .***/.*** pairings and that can be done utilizing other guides.
If done righ,t you can have an extension made available in the right type of system container to throttle any resources to it that you would like - and to use it with less worry that it will impact the rest of your system somehow.
To see more about the Logging and Auditing in C.ORE™ click HERE
