@peers-app/peers-ui 0.15.4 → 0.16.0
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/.github/workflows/publish.yml +3 -3
- package/dist/components/markdown-editor/editor.js +3 -1
- package/dist/components/markdown-editor/move-line-plugin.d.ts +18 -0
- package/dist/components/markdown-editor/move-line-plugin.js +161 -0
- package/dist/components/markdown-editor/select-line-boundary-plugin.d.ts +8 -0
- package/dist/components/markdown-editor/select-line-boundary-plugin.js +71 -0
- package/dist/screens/data-explorer/data-explorer.js +64 -16
- package/package.json +3 -3
- package/src/components/markdown-editor/editor.tsx +4 -0
- package/src/components/markdown-editor/move-line-plugin.tsx +186 -0
- package/src/components/markdown-editor/select-line-boundary-plugin.tsx +95 -0
- package/src/screens/data-explorer/data-explorer.tsx +271 -76
- package/docs/conversation-tab.md +0 -201
- package/docs/getting-started.md +0 -284
- package/docs/knowledge.md +0 -187
- package/docs/tabs-ui.md +0 -681
- package/docs/user-contacts-ui.md +0 -384
package/docs/getting-started.md
DELETED
|
@@ -1,284 +0,0 @@
|
|
|
1
|
-
# Peers UI Framework - Getting Started Guide
|
|
2
|
-
|
|
3
|
-
## Overview
|
|
4
|
-
|
|
5
|
-
The Peers UI Framework is a dynamic, package-based system that allows loading and rendering user-created UI components at runtime. It consists of two main systems working together: **Route Loading** and **UI Component Loading**.
|
|
6
|
-
|
|
7
|
-
## Key Concepts
|
|
8
|
-
|
|
9
|
-
### **Packages**
|
|
10
|
-
- Self-contained bundles of code stored in the database
|
|
11
|
-
- Each package can contain both route definitions and UI components
|
|
12
|
-
- Packages have `routesBundleFileId` and `uiBundleFileId` fields
|
|
13
|
-
|
|
14
|
-
### **Routes**
|
|
15
|
-
- Define which URLs map to which UI components
|
|
16
|
-
- Support path matching, props validation, and conditional rendering
|
|
17
|
-
- Registered globally and matched dynamically
|
|
18
|
-
|
|
19
|
-
### **UI Components**
|
|
20
|
-
- React components loaded on-demand from package bundles
|
|
21
|
-
- Wrapped in error boundaries for safe loading
|
|
22
|
-
- Support props validation with Zod schemas
|
|
23
|
-
|
|
24
|
-
## System Architecture
|
|
25
|
-
|
|
26
|
-
```mermaid
|
|
27
|
-
graph TB
|
|
28
|
-
subgraph "Package Storage"
|
|
29
|
-
DB[(Database)]
|
|
30
|
-
PkgA[Package A<br/>routes + UI bundles]
|
|
31
|
-
PkgB[Package B<br/>routes + UI bundles]
|
|
32
|
-
DB --> PkgA
|
|
33
|
-
DB --> PkgB
|
|
34
|
-
end
|
|
35
|
-
|
|
36
|
-
subgraph "Route System"
|
|
37
|
-
RL[routes-loader.ts]
|
|
38
|
-
WR[Window Route Registry]
|
|
39
|
-
RL --> WR
|
|
40
|
-
end
|
|
41
|
-
|
|
42
|
-
subgraph "UI System"
|
|
43
|
-
UL[ui-loader.tsx]
|
|
44
|
-
UR[UIRouter]
|
|
45
|
-
UC[UILoader]
|
|
46
|
-
UL --> UR --> UC
|
|
47
|
-
end
|
|
48
|
-
|
|
49
|
-
subgraph "Runtime"
|
|
50
|
-
APP[App Component]
|
|
51
|
-
TABS[TabsLayout]
|
|
52
|
-
ROUTER[Router Component]
|
|
53
|
-
APP --> TABS --> ROUTER
|
|
54
|
-
end
|
|
55
|
-
|
|
56
|
-
PkgA --> RL
|
|
57
|
-
PkgB --> RL
|
|
58
|
-
WR --> UR
|
|
59
|
-
ROUTER --> UR
|
|
60
|
-
```
|
|
61
|
-
|
|
62
|
-
## Loading Sequence
|
|
63
|
-
|
|
64
|
-
```mermaid
|
|
65
|
-
sequenceDiagram
|
|
66
|
-
participant App
|
|
67
|
-
participant RL as routes-loader
|
|
68
|
-
participant DB as Database
|
|
69
|
-
participant WR as Window Registry
|
|
70
|
-
participant UI as ui-loader
|
|
71
|
-
participant USER as User Navigation
|
|
72
|
-
|
|
73
|
-
Note over App,USER: 1. Application Startup
|
|
74
|
-
App->>RL: loadAllRoutes()
|
|
75
|
-
RL->>DB: Get packages with routesBundleFileId
|
|
76
|
-
DB-->>RL: Package list
|
|
77
|
-
|
|
78
|
-
Note over RL,WR: 2. Routes Registration
|
|
79
|
-
loop For each package
|
|
80
|
-
RL->>DB: Download routes bundle code
|
|
81
|
-
DB-->>RL: Bundle JavaScript code
|
|
82
|
-
RL->>RL: Execute bundle via new Function()
|
|
83
|
-
RL->>WR: registerPeersUIRoute(routes)
|
|
84
|
-
end
|
|
85
|
-
|
|
86
|
-
Note over USER,UI: 3. User Navigation
|
|
87
|
-
USER->>App: Navigate to /some-path
|
|
88
|
-
App->>UI: UIRouter({ path: '/some-path' })
|
|
89
|
-
UI->>WR: Find matching route
|
|
90
|
-
WR-->>UI: Route with peersUIId
|
|
91
|
-
|
|
92
|
-
Note over UI,DB: 4. Component Loading
|
|
93
|
-
UI->>UI: Check if component cached
|
|
94
|
-
alt Component not cached
|
|
95
|
-
UI->>DB: Download UI bundle code
|
|
96
|
-
DB-->>UI: Component JavaScript code
|
|
97
|
-
UI->>UI: Execute bundle, register component
|
|
98
|
-
end
|
|
99
|
-
UI->>UI: Render component with error boundary
|
|
100
|
-
UI-->>App: React Component
|
|
101
|
-
```
|
|
102
|
-
|
|
103
|
-
## Route Registration Flow
|
|
104
|
-
|
|
105
|
-
### 1. **Package Discovery**
|
|
106
|
-
```typescript
|
|
107
|
-
// routes-loader.ts finds packages with UI capabilities
|
|
108
|
-
let packagesWithUI = await Packages().list({
|
|
109
|
-
disabled: { $ne: true },
|
|
110
|
-
routesBundleFileId: { $exists: true },
|
|
111
|
-
});
|
|
112
|
-
```
|
|
113
|
-
|
|
114
|
-
### 2. **Route Bundle Execution**
|
|
115
|
-
```typescript
|
|
116
|
-
// Download and execute route bundle code
|
|
117
|
-
const bundleCode = await rpcServerCalls.getFileContents(pkg.routesBundleFileId);
|
|
118
|
-
const exportRoutes = (peerRoutes) => {
|
|
119
|
-
peerRoutes.routes.forEach(route => {
|
|
120
|
-
window.registerPeersUIRoute(route); // Register globally
|
|
121
|
-
});
|
|
122
|
-
}
|
|
123
|
-
const bundleFunction = new Function('exportRoutes', bundleCode);
|
|
124
|
-
bundleFunction(exportRoutes);
|
|
125
|
-
```
|
|
126
|
-
|
|
127
|
-
### 3. **Route Matching**
|
|
128
|
-
```typescript
|
|
129
|
-
// UIRouter matches incoming paths against registered routes
|
|
130
|
-
const allRoutes = window.getPeersUIRoutes();
|
|
131
|
-
const matchingRoute = allRoutes.find(route => {
|
|
132
|
-
// Path matching (supports regex)
|
|
133
|
-
// Props validation
|
|
134
|
-
// Conditional matching via isMatch()
|
|
135
|
-
});
|
|
136
|
-
```
|
|
137
|
-
|
|
138
|
-
## UI Component Loading Flow
|
|
139
|
-
|
|
140
|
-
### 1. **Component Discovery**
|
|
141
|
-
```typescript
|
|
142
|
-
// UIRouter delegates to UILoader with matched route
|
|
143
|
-
return UILoader({ peersUIId: matchingRoute.peersUIId, props });
|
|
144
|
-
```
|
|
145
|
-
|
|
146
|
-
### 2. **Bundle Loading**
|
|
147
|
-
```typescript
|
|
148
|
-
// Download UI bundle if not cached
|
|
149
|
-
const bundleCode = await rpcServerCalls.getFileContents(pkg.uiBundleFileId);
|
|
150
|
-
const exportUIs = (peerUIs) => {
|
|
151
|
-
peerUIs.uis.forEach(ui => {
|
|
152
|
-
peersUIs[ui.peersUIId] = ui; // Cache component
|
|
153
|
-
});
|
|
154
|
-
}
|
|
155
|
-
const bundleFunction = new Function('exportUIs', bundleCode);
|
|
156
|
-
bundleFunction(exportUIs);
|
|
157
|
-
```
|
|
158
|
-
|
|
159
|
-
### 3. **Component Rendering**
|
|
160
|
-
```typescript
|
|
161
|
-
// Render cached component with error boundary
|
|
162
|
-
const Component = peersUI.content;
|
|
163
|
-
return (
|
|
164
|
-
<UIErrorBoundary peersUIId={peersUIId}>
|
|
165
|
-
<Component {...props} />
|
|
166
|
-
</UIErrorBoundary>
|
|
167
|
-
);
|
|
168
|
-
```
|
|
169
|
-
|
|
170
|
-
## Error Handling
|
|
171
|
-
|
|
172
|
-
The framework provides comprehensive error handling:
|
|
173
|
-
|
|
174
|
-
### **Route Loading Errors**
|
|
175
|
-
- Invalid bundle code execution
|
|
176
|
-
- Missing route bundle files
|
|
177
|
-
- Network failures during download
|
|
178
|
-
|
|
179
|
-
### **UI Component Errors**
|
|
180
|
-
- Bundle loading failures with retry mechanism
|
|
181
|
-
- Props validation errors with detailed feedback
|
|
182
|
-
- Runtime component errors with error boundaries
|
|
183
|
-
|
|
184
|
-
### **Error UI Examples**
|
|
185
|
-
```typescript
|
|
186
|
-
// Bundle Loading Error
|
|
187
|
-
<div style={{ border: '2px solid #ff6b6b' }}>
|
|
188
|
-
<h3>Bundle Loading Error</h3>
|
|
189
|
-
<div>Package: {pkg.name}</div>
|
|
190
|
-
<button onClick={retry}>Retry Loading</button>
|
|
191
|
-
</div>
|
|
192
|
-
|
|
193
|
-
// Props Validation Error
|
|
194
|
-
<div>Props did not match schema</div>
|
|
195
|
-
<pre>{JSON.stringify(validationError, null, 2)}</pre>
|
|
196
|
-
```
|
|
197
|
-
|
|
198
|
-
## Integration Points
|
|
199
|
-
|
|
200
|
-
### **System Apps vs Package Apps**
|
|
201
|
-
|
|
202
|
-
| System Apps | Package Apps |
|
|
203
|
-
|-------------|--------------|
|
|
204
|
-
| Built into peers-ui | Loaded from database |
|
|
205
|
-
| Direct router integration | Dynamic route registration |
|
|
206
|
-
| Immediate availability | Async loading required |
|
|
207
|
-
| Examples: Tools, Assistants | Examples: Custom user apps |
|
|
208
|
-
|
|
209
|
-
### **TabsLayout Integration**
|
|
210
|
-
```typescript
|
|
211
|
-
// System apps integrated directly
|
|
212
|
-
const systemApps = [assistantsApp, toolsApp, workflowsApp];
|
|
213
|
-
|
|
214
|
-
// Package apps discovered dynamically
|
|
215
|
-
const [packages] = useObservable(allPackages);
|
|
216
|
-
const appPackages = packages.filter(p => !p.disabled && p.appNavs?.length);
|
|
217
|
-
```
|
|
218
|
-
|
|
219
|
-
### **Router Integration**
|
|
220
|
-
```typescript
|
|
221
|
-
// TabsLayout calls Router for content rendering
|
|
222
|
-
const renderTabContent = (tab) => {
|
|
223
|
-
return <Router path={tab.path} />;
|
|
224
|
-
};
|
|
225
|
-
|
|
226
|
-
// Router attempts UIRouter before falling back to system routes
|
|
227
|
-
const ui = UIRouter({ path, props: {}, uiCategory: 'screen' });
|
|
228
|
-
if (ui) return ui;
|
|
229
|
-
// ... fallback to system routes
|
|
230
|
-
```
|
|
231
|
-
|
|
232
|
-
## Development Workflow
|
|
233
|
-
|
|
234
|
-
### **Creating a New Package App**
|
|
235
|
-
|
|
236
|
-
1. **Create Route Bundle**: Define routes that map paths to component IDs
|
|
237
|
-
2. **Create UI Bundle**: Implement React components with props validation
|
|
238
|
-
3. **Package Registration**: Store bundles in database with proper file IDs
|
|
239
|
-
4. **App Navigation**: Add app navigation metadata for tabs integration
|
|
240
|
-
|
|
241
|
-
### **Package Bundle Structure**
|
|
242
|
-
```javascript
|
|
243
|
-
// Route Bundle (executed at startup)
|
|
244
|
-
exportRoutes({
|
|
245
|
-
routes: [{
|
|
246
|
-
peersUIId: 'my-component-id',
|
|
247
|
-
path: '/my-app',
|
|
248
|
-
uiCategory: 'screen',
|
|
249
|
-
propsSchema: z.object({ id: z.string() }),
|
|
250
|
-
isMatch: (props, context) => true
|
|
251
|
-
}]
|
|
252
|
-
});
|
|
253
|
-
|
|
254
|
-
// UI Bundle (loaded on-demand)
|
|
255
|
-
exportUIs({
|
|
256
|
-
uis: [{
|
|
257
|
-
peersUIId: 'my-component-id',
|
|
258
|
-
content: MyReactComponent,
|
|
259
|
-
propsSchema: z.object({ id: z.string() })
|
|
260
|
-
}]
|
|
261
|
-
});
|
|
262
|
-
```
|
|
263
|
-
|
|
264
|
-
## Performance Characteristics
|
|
265
|
-
|
|
266
|
-
### **Optimizations**
|
|
267
|
-
- **Lazy Loading**: UI bundles loaded only when needed
|
|
268
|
-
- **Caching**: Components cached in memory after first load
|
|
269
|
-
- **Bundle Splitting**: Routes and UI separated for faster startup
|
|
270
|
-
- **Error Boundaries**: Component failures don't crash entire app
|
|
271
|
-
|
|
272
|
-
### **Bundle Size Impact**
|
|
273
|
-
- Small route bundles loaded at startup (fast)
|
|
274
|
-
- Large UI bundles loaded on-demand (UX optimized)
|
|
275
|
-
- Each package isolated (no dependency conflicts)
|
|
276
|
-
|
|
277
|
-
## Next Steps
|
|
278
|
-
|
|
279
|
-
- **[System Apps Guide](architecture/system-apps.md)** - Learn system app patterns
|
|
280
|
-
- **[Router Patterns](architecture/router-patterns.md)** - Advanced routing techniques
|
|
281
|
-
- **[Component Library](components/component-library.md)** - Reusable UI components
|
|
282
|
-
- **[Groups Implementation Example](examples/groups-implementation.md)** - Real-world implementation guide
|
|
283
|
-
|
|
284
|
-
This framework enables a truly extensible application where users can create and share custom UI components while maintaining system stability and performance.
|
package/docs/knowledge.md
DELETED
|
@@ -1,187 +0,0 @@
|
|
|
1
|
-
### Scratchpad
|
|
2
|
-
|
|
3
|
-
Implementation
|
|
4
|
-
- [x] Ability to add notes
|
|
5
|
-
- [ ] Ability to paste raw markdown
|
|
6
|
-
- [ ] Need to be able to mark up paragraphs (or just parts of notes) with metadata
|
|
7
|
-
- [ ] turn task list items into distinct, top-level tasks
|
|
8
|
-
- implement logical argument system
|
|
9
|
-
- [ ] classify and critique
|
|
10
|
-
- implement PKS
|
|
11
|
-
- [ ] asdf
|
|
12
|
-
|
|
13
|
-
---
|
|
14
|
-
|
|
15
|
-
### Key Components for Argument Breakdown System:
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
1. **Premise Classification**
|
|
19
|
-
- Explicit premises
|
|
20
|
-
- Clearly stated and directly presented within the argument
|
|
21
|
-
- Implicit premises
|
|
22
|
-
- Not directly stated but is assumed or inferred by the audience to complete the argument. Implicit premises often rely on shared knowledge or common understanding to be recognized.
|
|
23
|
-
|
|
24
|
-
2. **Inference & Conclusion Classification**
|
|
25
|
-
- Deductive
|
|
26
|
-
- Derived from deductive reasoning, where if the premises are true, the conclusion must be true.
|
|
27
|
-
- Guarantees the truth of the conclusion if the premises are true
|
|
28
|
-
- Inductive
|
|
29
|
-
- Generalizes from specific instances
|
|
30
|
-
- Based on inductive reasoning, where the conclusion is likely but not guaranteed, derived from specific observations.
|
|
31
|
-
- Abductive
|
|
32
|
-
- Involves finding the most plausible explanation for a set of observations, often used in hypothesis generation.
|
|
33
|
-
- Starts with an observation or set of observations and seeks the simplest and most likely explanation
|
|
34
|
-
- Analogical
|
|
35
|
-
- Drawn from analogical reasoning, where similarities between two situations lead to a conclusion about one based on the other.
|
|
36
|
-
- Probabilistic
|
|
37
|
-
- Involves conclusions that are expressed in terms of probability, often used in statistical reasoning.
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
3. **Evidence Categorization**
|
|
41
|
-
- Facts
|
|
42
|
-
- Statistics
|
|
43
|
-
- Examples (empirical or anecdotal)
|
|
44
|
-
- Clearly define what constitutes empirical versus anecdotal evidence to avoid ambiguity.
|
|
45
|
-
|
|
46
|
-
4. **Fallacy Detection**
|
|
47
|
-
- Ad Hominem
|
|
48
|
-
- Attacking the person instead of the argument.
|
|
49
|
-
- Straw Man
|
|
50
|
-
- Misrepresenting an argument to make it easier to attack.
|
|
51
|
-
- Appeal to Ignorance
|
|
52
|
-
- Claiming something is true because it hasn't been proven false.
|
|
53
|
-
- False Dilemma
|
|
54
|
-
- Presenting two options as the only possibilities.
|
|
55
|
-
- Slippery Slope
|
|
56
|
-
- Arguing that a small step will lead to a chain of events resulting in a significant impact.
|
|
57
|
-
- Circular Reasoning
|
|
58
|
-
- The conclusion is included in the premise.
|
|
59
|
-
- Hasty Generalization
|
|
60
|
-
- Making a broad claim based on limited evidence.
|
|
61
|
-
- Red Herring
|
|
62
|
-
- Introducing irrelevant information to distract from the main issue.
|
|
63
|
-
- Appeal to Authority
|
|
64
|
-
- Believing a claim is true because an authority figure endorses it.
|
|
65
|
-
- Post Hoc
|
|
66
|
-
- Assuming that because one event followed another, it was caused by it.
|
|
67
|
-
|
|
68
|
-
### Notes:
|
|
69
|
-
|
|
70
|
-
- Ensure the system can identify and handle contradictions within the premises or between the premises and the conclusion effectively.
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
1. **Contextual Analysis:**
|
|
74
|
-
- Incorporate a module to understand the context in which the argument is made. Context can influence the interpretation of premises and conclusions.
|
|
75
|
-
- The context of the argument can result in wildly different outcomes
|
|
76
|
-
|
|
77
|
-
2. **User Feedback Loop:**
|
|
78
|
-
- Implement a feedback mechanism where users can validate or dispute the system's interpretation of the argument. This can help in refining the accuracy of the system over time.
|
|
79
|
-
|
|
80
|
-
3. **Semantic Analysis:**
|
|
81
|
-
- Use natural language processing to detect nuances in language that might affect the interpretation of premises and conclusions.
|
|
82
|
-
|
|
83
|
-
4. **Source Credibility:**
|
|
84
|
-
- Evaluate the credibility of sources cited in the argument. This can be crucial in assessing the reliability of the evidence presented.
|
|
85
|
-
|
|
86
|
-
5. **Argument Strength Assessment:**
|
|
87
|
-
- Develop a metric to assess the strength of the argument based on the robustness of the logical structure and the quality of evidence.
|
|
88
|
-
|
|
89
|
-
6. **Multi-perspective Analysis:**
|
|
90
|
-
- Allow for the analysis of arguments from multiple perspectives to understand how different viewpoints might interpret the same set of facts differently.
|
|
91
|
-
|
|
92
|
-
---
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
**Note / Doc (Entry)**
|
|
96
|
-
- This will be any entry from the user
|
|
97
|
-
- Everything starts here
|
|
98
|
-
- User's can "assert" that it is a "argument part"
|
|
99
|
-
-
|
|
100
|
-
|
|
101
|
-
**Data**
|
|
102
|
-
- This is a critically different in that it is meant to be entered in a tabular format with statistical analysis applied
|
|
103
|
-
- gun data like deaths, incidents of self defense, etc. can be used to assert wildly different conclusions
|
|
104
|
-
- Instead of being raw markdown it's tabular data
|
|
105
|
-
- I _think_ everything else can just be markdown?
|
|
106
|
-
|
|
107
|
-
Parts
|
|
108
|
-
- Premises / Assumptions / Givens
|
|
109
|
-
- supporting data
|
|
110
|
-
|
|
111
|
-
Data
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
---
|
|
116
|
-
|
|
117
|
-
### Questions as starting point
|
|
118
|
-
- the idea here is to move away from the "logical arguments" structure and into the "I have a question that I want answered"
|
|
119
|
-
- potential forms:
|
|
120
|
-
- Question + accepted + alternate answers
|
|
121
|
-
- Jeopardy - I have an answer, what's the question
|
|
122
|
-
- ...
|
|
123
|
-
- This would still have entry types
|
|
124
|
-
- observations / notes
|
|
125
|
-
- "this is how I do this"
|
|
126
|
-
- "this happened on this day"
|
|
127
|
-
- conclusions from data
|
|
128
|
-
- A / B test results
|
|
129
|
-
|
|
130
|
-
The big pull for this is that it seems the most useful with real-world application. At the same time, how many QA sites already exist (Stack overflow, Quora, Google in a way, etc.).
|
|
131
|
-
|
|
132
|
-
So I think I'm getting tangled up trying to marry a note-taking system to a logical argument system to a personal knowledge system (PKS).
|
|
133
|
-
|
|
134
|
-
Notes should absolutely be part of the system but the real goal here is to "help users perceive truth from untruth". So the logical argument part should be front and center. Also the PKS aspect of this seems like a direct extension of the logical argument system and appropriate to include. Finally, remember I think this is a problem uniquely suited to LLMs which can act as a kind of compiler and greatly streamline and automate the process of formalizing one's thoughts on a give subject.
|
|
135
|
-
|
|
136
|
-
So the features are
|
|
137
|
-
- Raw entries
|
|
138
|
-
- logical arguments
|
|
139
|
-
- categorize paragraphs into
|
|
140
|
-
- Premise
|
|
141
|
-
- Inference
|
|
142
|
-
- Automatically highlight
|
|
143
|
-
- Inference type used
|
|
144
|
-
- Critical Assumptions
|
|
145
|
-
- Fallacies
|
|
146
|
-
- personal knowledge system
|
|
147
|
-
- links
|
|
148
|
-
- search
|
|
149
|
-
- "workspace" which pulls on notes and LLM calls out unifying thread
|
|
150
|
-
- this is basically a "hub note" I think
|
|
151
|
-
|
|
152
|
-
In some sense this is a PKS with the logical arguments kind of imposed on top. That actually sounds pretty good. **So start with the notes (raw entries)**
|
|
153
|
-
|
|
154
|
-
The UI for going from "raw entry" to classified argument parts is very key. Ideas:
|
|
155
|
-
- Jupyter Notebook format
|
|
156
|
-
- raw entries have paragraphs. Each paragraph is an atomic "raw entry".
|
|
157
|
-
- The system adds metadata to the paragraph (Premise, Inference type, etc) as well as the "Notebook / Document"
|
|
158
|
-
- A sidebar can contain related content from other parts of the system
|
|
159
|
-
- This will often be auto-populated by the LLM using vector search
|
|
160
|
-
- It or a related sidebar can be populated by the user with atomic notes that the user wants to try to incorporate or just wants available as a reference.
|
|
161
|
-
|
|
162
|
-
- Workspace format
|
|
163
|
-
- A space with cards that can be dragged around and rearranged into hierarchies, progressions, etc.
|
|
164
|
-
- This would be more of a graphical UI
|
|
165
|
-
- Cards can represent different things
|
|
166
|
-
- Another workspace / document (show a summary or title or key conclusion)
|
|
167
|
-
- An atomic entry (raw input)
|
|
168
|
-
- ...
|
|
169
|
-
- This feels pretty complicated to implement...
|
|
170
|
-
|
|
171
|
-
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
---
|
|
176
|
-
|
|
177
|
-
### Raw Entries
|
|
178
|
-
|
|
179
|
-
I think I'd rather start with raw entries and allow them to be structured as logical arguments or questions and answers or whatever. The base is the raw entry though. This is the most natural and flexible.
|
|
180
|
-
|
|
181
|
-
Structure
|
|
182
|
-
- Raw entry has a title (required) and body (not required)
|
|
183
|
-
|
|
184
|
-
Now how do we add structure on top of that for logical arguments, types (premise, assumption, conclusion, question or answer, etc.)
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|