@sockethub/client 5.0.0-alpha.12 → 5.0.0-alpha.13
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 +42 -20
- package/dist/sockethub-client.browser.js +279 -908
- package/dist/sockethub-client.d.ts +280 -0
- package/dist/sockethub-client.js +273 -895
- package/dist/sockethub-client.min.js +21 -36
- package/package.json +6 -7
- package/src/sockethub-client.test.ts +0 -797
- package/src/sockethub-client.ts +0 -1095
package/README.md
CHANGED
|
@@ -2,19 +2,47 @@
|
|
|
2
2
|
|
|
3
3
|
The Sockethub client is a small JavaScript SDK for app developers to connect to a
|
|
4
4
|
Sockethub server via Socket.IO and send/receive ActivityStreams messages. It works
|
|
5
|
-
in both Node.js and browsers,
|
|
6
|
-
|
|
5
|
+
in both Node.js and browsers, with schema-driven validation, automatic
|
|
6
|
+
reconnection, and credential replay.
|
|
7
7
|
|
|
8
8
|
## What's Included
|
|
9
9
|
|
|
10
10
|
- `SockethubClient` for connection and message handling
|
|
11
|
-
-
|
|
11
|
+
- Schema-driven validation of outbound ActivityStreams messages (via `@sockethub/schemas`)
|
|
12
12
|
- `contextFor(platform)` builds canonical `@context` arrays from server metadata
|
|
13
13
|
- `ready()` promise and `ready`/`init_error` observability events
|
|
14
|
-
- Automatic outbound
|
|
14
|
+
- Automatic outbound queuing until initialization is complete
|
|
15
15
|
- Auto-replay of credentials and connections on reconnect
|
|
16
16
|
- A browser-ready bundle in `dist/`
|
|
17
17
|
|
|
18
|
+
## How It Works
|
|
19
|
+
|
|
20
|
+
`SockethubClient` wraps a [Socket.IO](https://socket.io) connection and manages
|
|
21
|
+
everything between your app and the Sockethub server:
|
|
22
|
+
|
|
23
|
+
1. **Schema registry handshake.** On connect (and every reconnect) the client
|
|
24
|
+
requests the server's *platform schema registry* — the contexts, versions,
|
|
25
|
+
and JSON schemas for each platform the server has loaded. It caches that
|
|
26
|
+
registry along with a content fingerprint the server provides. On reconnect
|
|
27
|
+
the client echoes the fingerprint; if nothing has changed the server replies
|
|
28
|
+
`unchanged` instead of re-sending the full schema set, so the (potentially
|
|
29
|
+
large) registry crosses the wire only when it actually changes.
|
|
30
|
+
2. **Initialization lifecycle.** `ready()` resolves once the registry is
|
|
31
|
+
applied; `getInitState()` and the `ready` / `init_error` events expose the
|
|
32
|
+
same lifecycle. Outbound events emitted before the client is ready are queued
|
|
33
|
+
in memory and flushed automatically once initialization completes.
|
|
34
|
+
3. **Message handling.** Outgoing `message`/`credentials` events are normalized
|
|
35
|
+
(string `actor`/`target` references are expanded to objects) and validated
|
|
36
|
+
against the originating platform's schema before they leave the client;
|
|
37
|
+
incoming platform events are normalized before being handed to your
|
|
38
|
+
`message` listener. Validation uses the same schemas the server enforces, so
|
|
39
|
+
malformed activities are caught locally rather than round-tripping.
|
|
40
|
+
4. **Context composition.** `contextFor(platform)` builds the canonical
|
|
41
|
+
`@context` array for a platform from the cached registry.
|
|
42
|
+
5. **Reconnect resilience.** Credentials, platform connections, and room joins
|
|
43
|
+
are kept in memory and replayed when the socket reconnects (see
|
|
44
|
+
[Security & State Management](#security--state-management)).
|
|
45
|
+
|
|
18
46
|
## Install
|
|
19
47
|
|
|
20
48
|
### Node.js
|
|
@@ -115,7 +143,8 @@ See the [Client Guide](../../docs/client-guide.md) for detailed usage and exampl
|
|
|
115
143
|
- **`sc.socket.emit(event, data, callback)`** - Send messages (queued until ready)
|
|
116
144
|
- **`sc.socket.on(event, handler)`** - Listen for messages
|
|
117
145
|
- **`sc.clearCredentials()`** - Clear stored credentials
|
|
118
|
-
|
|
146
|
+
|
|
147
|
+
Send a full `actor` object on each `credentials` and `message` event.
|
|
119
148
|
|
|
120
149
|
## Result Handling
|
|
121
150
|
|
|
@@ -146,26 +175,20 @@ sc.socket.on("message", (msg) => {
|
|
|
146
175
|
});
|
|
147
176
|
```
|
|
148
177
|
|
|
149
|
-
##
|
|
178
|
+
## Sending messages
|
|
150
179
|
|
|
151
|
-
|
|
152
|
-
|
|
180
|
+
Include `id`, `type`, and usually `name` on the `actor` for `credentials` and
|
|
181
|
+
`message` events. Before sending, the client validates each outgoing activity
|
|
182
|
+
against the originating platform's schema from the server registry, surfacing a
|
|
183
|
+
client-side error instead of dispatching a malformed message.
|
|
153
184
|
|
|
154
185
|
```javascript
|
|
155
|
-
sc.
|
|
156
|
-
id: "mynick",
|
|
157
|
-
type: "person",
|
|
158
|
-
name: "My IRC Nick",
|
|
159
|
-
});
|
|
160
|
-
|
|
161
|
-
const stream = sc.ActivityStreams.Stream({
|
|
186
|
+
sc.socket.emit("message", {
|
|
162
187
|
type: "join",
|
|
163
188
|
"@context": sc.contextFor("irc"),
|
|
164
|
-
actor: "mynick",
|
|
189
|
+
actor: { id: "mynick", type: "person", name: "My IRC Nick" },
|
|
165
190
|
target: { id: "#sockethub", type: "room" },
|
|
166
|
-
})
|
|
167
|
-
|
|
168
|
-
sc.socket.emit("message", stream, (result) => {
|
|
191
|
+
}, (result) => {
|
|
169
192
|
if (result?.error) console.error(result.error);
|
|
170
193
|
});
|
|
171
194
|
```
|
|
@@ -180,7 +203,6 @@ memory and replaying it when the connection is re-established.
|
|
|
180
203
|
#### What Gets Stored
|
|
181
204
|
|
|
182
205
|
- Credentials (passwords, tokens, API keys)
|
|
183
|
-
- Actor definitions
|
|
184
206
|
- Platform connections
|
|
185
207
|
- Channel/room joins
|
|
186
208
|
|