this.me 2.7.7 → 2.7.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +82 -58
- package/docs/Me.html +697 -0
- package/docs/README.md +91 -0
- package/docs/ThisMe.html +690 -0
- package/docs/cli_main.js.html +340 -0
- package/docs/fonts/OpenSans-Bold-webfont.eot +0 -0
- package/docs/fonts/OpenSans-Bold-webfont.svg +1830 -0
- package/docs/fonts/OpenSans-Bold-webfont.woff +0 -0
- package/docs/fonts/OpenSans-BoldItalic-webfont.eot +0 -0
- package/docs/fonts/OpenSans-BoldItalic-webfont.svg +1830 -0
- package/docs/fonts/OpenSans-BoldItalic-webfont.woff +0 -0
- package/docs/fonts/OpenSans-Italic-webfont.eot +0 -0
- package/docs/fonts/OpenSans-Italic-webfont.svg +1830 -0
- package/docs/fonts/OpenSans-Italic-webfont.woff +0 -0
- package/docs/fonts/OpenSans-Light-webfont.eot +0 -0
- package/docs/fonts/OpenSans-Light-webfont.svg +1831 -0
- package/docs/fonts/OpenSans-Light-webfont.woff +0 -0
- package/docs/fonts/OpenSans-LightItalic-webfont.eot +0 -0
- package/docs/fonts/OpenSans-LightItalic-webfont.svg +1835 -0
- package/docs/fonts/OpenSans-LightItalic-webfont.woff +0 -0
- package/docs/fonts/OpenSans-Regular-webfont.eot +0 -0
- package/docs/fonts/OpenSans-Regular-webfont.svg +1831 -0
- package/docs/fonts/OpenSans-Regular-webfont.woff +0 -0
- package/docs/global.html +454 -0
- package/docs/index.html +258 -0
- package/docs/me.js.html +211 -0
- package/docs/module-CLI.html +963 -0
- package/docs/neurons_logo.png +0 -0
- package/docs/scripts/app.min.js +1 -0
- package/docs/scripts/linenumber.js +26 -0
- package/docs/scripts/prettify/Apache-License-2.0.txt +202 -0
- package/docs/scripts/prettify/lang-css.js +2 -0
- package/docs/scripts/prettify/prettify.js +28 -0
- package/docs/scripts/search.js +39 -0
- package/docs/styles/app.min.css +1 -0
- package/docs/styles/iframe.css +13 -0
- package/docs/styles/jsdoc-default.css +358 -0
- package/docs/styles/prettify-jsdoc.css +111 -0
- package/docs/styles/prettify-tomorrow.css +132 -0
- package/docs/styles/reset.css +44 -0
- package/jsdoc.json +43 -0
- package/package.json +22 -29
- package/src/cli/main.js +176 -0
- package/src/env.js +8 -0
- package/{me.html → src/me.html} +1 -0
- package/src/me.js +47 -0
- package/src/os/unix/install_me.sh +5 -0
- package/src/this/video.js +0 -0
- package/Me.js +0 -71
- package/crypto/crypto-browser.js +0 -20
- package/crypto/crypto-node.js +0 -16
- package/crypto/hash/hashWorker.js +0 -11
- package/crypto/hash/hashing.js +0 -43
- package/demo.js +0 -12
- package/main.js +0 -77
- package/me2.js +0 -57
- package/src/errorHandler.js +0 -9
- package/test.js +0 -36
- package/testHashIt.js +0 -3
- package/webpack.config.js +0 -18
- /package/{this/dir.js → index.js} +0 -0
- /package/{this/file.js → src/this/dir.js} +0 -0
- /package/{this/url.js → src/this/file.js} +0 -0
- /package/{this/video.js → src/this/url.js} +0 -0
package/README.md
CHANGED
|
@@ -1,68 +1,92 @@
|
|
|
1
|
-
<img src="
|
|
1
|
+
<img src="https://suign.github.io/neurons.me/neurons_logo.png" alt="SVG Image" width="123" height="123" style="width123px; height:123px;">
|
|
2
2
|
|
|
3
|
-
# .
|
|
4
|
-
I decided to circumvent the monotony of user session code and dive into the cryptographic labyrinth.
|
|
5
|
-
I'd sooner recode the Old and New Testaments, heck, throw in the Qabala too, in ASCII, before willingly plunging into the dull abyss of server-side user session management.
|
|
3
|
+
# This.Me
|
|
6
4
|
|
|
7
|
-
# Setting up your Context. 👋🏻👋🏼👋🏽👋🏾👋🏿
|
|
8
|
-
Defining the **environment** and context in which your code runs, especially when you're interacting with intelligent agents or services like **me.**
|
|
9
|
-
Having a clear declaration of the environment and the context can have a series of implications for security, interoperability, and clarity. The codebase is often vast, dynamic, and continually evolving. Given the dynamic nature of such environments, ensuring the integrity of the code and data becomes paramount. You wouldn't want an agent to execute or rely on code that has been tampered with or is different from the expected version. This is where hashing comes into play.
|
|
10
|
-
Continue reading about this:
|
|
11
|
-
https://www.mlearning.studio/data-formats/this-me
|
|
12
5
|
|
|
13
|
-
|
|
14
|
-
|
|
6
|
+
**This.Me** is a digital identity representation of **Me** as it encapsulates the essence of an entity which is then passed for cryptographic guarantees.
|
|
7
|
+
|
|
8
|
+
Users no longer depend on centralized authorities for **identity and data management**. They hold the keys (literally) to their identity and data.
|
|
9
|
+
|
|
10
|
+
Services become more **user-centric,** providing services based on cryptographic proofs rather than centralized authorities.
|
|
11
|
+
|
|
12
|
+
Here, you don't just own your identity; you seal it with cryptographic brilliance, untouched and ungoverned by any other.
|
|
13
|
+
|
|
14
|
+
## Getting Started:
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
npm i -g this.me
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
### Require it:
|
|
15
21
|
|
|
16
22
|
```js
|
|
17
|
-
const
|
|
23
|
+
const me = require('this.me');
|
|
18
24
|
```
|
|
19
25
|
|
|
26
|
+
### Usage Example:
|
|
27
|
+
|
|
28
|
+
Use it like this:
|
|
29
|
+
|
|
20
30
|
```js
|
|
21
|
-
|
|
22
|
-
const
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
// Example: Sign some data
|
|
26
|
-
const dataToSign = "Hello, World!";
|
|
27
|
-
const signature = suign.signData(dataToSign);
|
|
28
|
-
console.log("Signature for 'Hello, World!':", signature.toString('base64')); // Base64 encoding just to make the signature more readable in console.
|
|
29
|
-
// Example: Verify the signature
|
|
30
|
-
const isValidSignature = suign.verifySignature(dataToSign, signature);
|
|
31
|
-
console.log("Is the signature valid?", isValidSignature);
|
|
31
|
+
const ThisMe = require('this.me');
|
|
32
|
+
const user = new ThisMe('John', 'Doe', '1990-01-01', 'mypassword123', '1234');
|
|
33
|
+
const identityObject = user.getIdentityObject();
|
|
34
|
+
// identityObject can now be passed to Cleaker for hashing
|
|
32
35
|
```
|
|
33
36
|
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
37
|
+
## Understanding .ME
|
|
38
|
+
|
|
39
|
+
##### Structure of this.me Package:
|
|
40
|
+
|
|
41
|
+
**User Data Model:** Define a class or object structure to hold the user's data.
|
|
42
|
+
**Data Validation:** Functions to validate the input data.
|
|
43
|
+
**Data Processing:** Preparing data for hashing (by Cleaker).
|
|
44
|
+
**Exporting Data:** A method to export the processed data in a format that Cleaker can accept.
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
# Setting up your Context. 👋🏻👋🏼👋🏽👋🏾👋🏿
|
|
50
|
+
Defining the **environment** and context in which your code runs, especially when you're interacting with intelligent agents or services like **me.**
|
|
51
|
+
|
|
52
|
+
Having a clear declaration of the environment and the context can have a series of implications for security, interoperability, and clarity. The codebase is often vast, dynamic, and continually evolving. Given the dynamic nature of such environments, ensuring the integrity of the code and data becomes paramount. You wouldn't want an agent to execute or rely on code that has been tampered with or is different from the expected version. This is where hashing comes into play.
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
-----
|
|
57
|
+
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
`.me` objects to serve as both a local identity on the user's host machine and as an identity within a larger network. When a `.me` object is authenticated on a network, it can access data not only on the local host but also from other nodes within that network. Conversely, if it's not authenticated or recognized by the network, it should only access local data. Here's how this could be structured:
|
|
61
|
+
|
|
62
|
+
### Local and Network Identity Management
|
|
63
|
+
|
|
64
|
+
1. **Local Identity**:
|
|
65
|
+
- When a `.me` object is created, it's initially configured with access to local host resources.
|
|
66
|
+
- Users can manage their local profile, which includes their personal settings, preferences, and local data access permissions.
|
|
67
|
+
2. **Network Identity**:
|
|
68
|
+
- To access resources on the network, a `.me` object must be authenticated against the network, possibly by a central authority or a decentralized consensus mechanism.
|
|
69
|
+
- Once authenticated, the `.me` object's hash is recognized across the network, granting the user access to network resources according to their permissions.
|
|
70
|
+
3. **Access Control**:
|
|
71
|
+
- Both local and network resources use access control lists (ACLs) that are tied to the `.me` object's hash.
|
|
72
|
+
- These ACLs determine what resources the `.me` object can access and the level of interaction permitted (read, write, execute).
|
|
73
|
+
4. **Data Fetching**:
|
|
74
|
+
- When fetching data, the system checks if the `.me` object is authenticated within the network.
|
|
75
|
+
- If authenticated, the `.me` object can retrieve data from across the network based on the established ACLs.
|
|
76
|
+
- If not authenticated, the `.me` object is limited to retrieving data from the local host.
|
|
77
|
+
5. **CLI Functionality**:
|
|
78
|
+
- The CLI tool facilitates the creation of `.me` objects, management of profiles, and authentication processes.
|
|
79
|
+
- It could include commands to "login" to the network, "logout", or "sync" local profiles with network profiles.
|
|
80
|
+
6. **Data Sharing and Security**:
|
|
81
|
+
- Data sharing across the network should be secure, with encryption mechanisms in place to protect data in transit and at rest.
|
|
82
|
+
- The `.me` object's unique hash can be part of the encryption key, ensuring that only the intended `.me` object can decrypt and access the shared data.
|
|
83
|
+
|
|
84
|
+
### Example CLI Commands
|
|
85
|
+
|
|
86
|
+
- `me init`: Initializes a new `.me` object on the local host.
|
|
87
|
+
- `me login`: Authenticates the `.me` object against the network to access network resources.
|
|
88
|
+
- `me logout`: De-authenticates the `.me` object from the network, reverting to local-only access.
|
|
89
|
+
- `me sync`: Synchronizes local `.me` object data with the network profile.
|
|
90
|
+
- `me fetch`: Retrieves data from the local host or network based on authentication status.
|
|
91
|
+
|
|
92
|
+
By implementing this dual identity system, you enable a seamless transition for users between operating solely on their local device and engaging with a broader network, all while maintaining strict control over their data access rights.
|