2026-07-01
I posted the updates for data and material flow. Tomorrow I'll move on to a journal application. I've sidestepped the collaboration part. I'll have to come up with a good demonstration of that, as well as how to prune by ID and do replay over time.
2026-07-01
Heptad knowledge assertions reveal meaning within the app. With knowledge/material flow, this is most likely a layout and visualization program like #graphviz or #d3. But, for collaborative written language models like the original WWW, the assertions could be expressed directly in the browser.
2026-07-02
For domains where heptads are expressed directly by the browser, it is possible to have integrity and provenance directly from the HTML. Think of it as extremely scrappy and lightweight RDF (#BarrySmith of #suny would call it scruffy.) CSS could handle the layout directly. JS could layout/validate.
2026-07-03
I still don't think I need classes, only instances of model leaves (dreams has an instance_of a journal entry). When a node is placed, it has no meaning, just a UUIDv4. Origin must be a node as well. Predicates and non-relation objects can be human-readable. These need to be consistent for collaboration. As for the logical vs. physical, origin (a UUIDv4) only has the label origin. It can also have a URI or any other location string. This makes the models cumulative and completely distributed.
2026-07-03
The graph node (heptad element 1) must have an attribute for signature algorithm, for example, Ed25519 or secp256r1. This ensures the knowledge model is not tethered to any unneeded constraints, physical or otherwise. The model is portable between all messaging platforms (MQTT, Nostr, ATProto, HTTP, SMTP, SMS). The models are cumulative. A delete is an attribute on a new assertion (much like on Nostr relays).
2026-07-03
The root graph is always weird. Consistency appears to go away. This is the heptad for setting the signature algo:
[
"1d6af935-4fce-4880-b02f-2d06d745f617",
"1d6af935-4fce-4880-b02f-2d06d745f617",
"sig_algo",
"20260703T164458062Z",
"Ed25519",
"lxVBtHHttRoSq_isZPq3VCNJvU6Ks6dPuZ4RhAvfbcc",
"wi4LFiWPLsLNLbTlMFcqlBA7oPbY34aYKOd6qcLwMDFprepeoZzWLh-6vuYauZcGY2qh8ytF_7G2FeGydRgJCA"
]
In the graph (domain) of 1d6af935-4fce-4880-b02f-2d06d745f617, the 1d6af935-4fce-4880-b02f-2d06d745f617 subject has an attribute of sig_algo of Ed25519. This also explains what form the ID (heptad 5) is in (an Ed25519 public key). This is related to naked WWW domains.
2026-07-03
Notice that by removing physical, signature, and even ID bindings to URIs, message form, or algo, it is completely portable. I can assert a new form of signature algo at any time. Of course, you'd have to trust that I controlled the private key and you had a public ID that matched.
2026-07-03
My entire sojourn into origin and graph definitions this morning was because I realized all integrations of knowledge when fully distributed centered around the graph (heptad element G). I'm grooving on HTML presentation, and don't want to modify the heptads, as they have signatures. They are cumulative, so if Alice posts an origin page (index.html) and Bob wants to collaborate, Bob could either build off of Alice's graph directly by using the same ID, or just use Alice's predicates. By decoupling, it allows Bob to do stuff like use a different signature algorithm or expand the model in a different way. There should also be a similar choice for all nodes in collaboration. Bob might want to correct Alice's value. This is going a bit wide, but if Alice likes everything that Bob corrects except for a handful, Alice could exclude the edge made by quad. To picture how I intend this to work in reality, imagine multiple people just publishing a collection of HTML pages on the WWW. References to the graph could be set as an attribute. If Bob and Alice are working the same model, the graph "node" would have a URI reference. It could also have an nprofile or npub (although that limits the flexibility in Nostr land). I had to iron this out a bit and brainstorm (with myself... publicly in my ship's log) to get my bearings. Well... back to the JavaScript mines for now.
2026-07-04
I got the heptads to load in the HTML page directly. All that is left is to write the rendering code, now that the heptads are available in an object. I'm thinking that anything you want to collaborate on, you will see, first. So, since these are cumulative, Alice just views Bob's page, and the heptads are loaded into IndexedDB. Alice can modify/supplement, and post to her website, which will now contain both. Carol can view both and hers will update. A pub/sub w/ an MQTT topic of the graph ID?
2026-07-04
I need to be very careful on this, and consider the advantages to the simple version. It may well be that viewing somebody else's changes by reviewing their page and merging their changes at that point is better than being a viewer of a show that everybody watches and pokes at occasionally. I'll work out the simple version first, before adding more complex notifications. Also, this works offline. The key thing is the heptads which can be serialized and sent in many ways.
2026-07-04
I spent time this morning mulling over results of my embedded heptad experiments yesterday. I think the 3D form for data/material is the best to demonstrate collaboration on models, but my biggest focus in the coming year should be the journal application with light collaboration on entry comments.
2026-07-04
If I use showdownjs, I can publish my journal with zero external libraries. It will be all native, including signature verification. It has always been a dilemma to use markdown with a markdown library or render it prior. No more! Plus, the project is still active.
https://github.com/showdownjs/showdown
2026-07-04
Considering what flavor to use for showdown, and noticed that deity jgm says:
"My ambition is to eventually switch over to commonmark entirely, by implementing enough pandoc markdown extensions, but it's been slow."
So, Commonmark it is.
https://github.com/jgm/pandoc/issues/9329
2026-07-04
Hetpad 7 (Ed25519 sig in URL safe base64) serves as the unique ID for the entire heptad. I assemble the needed heptads for each page, prior, and this leads to duplicates. Using a JS Set to store them by H7 works well as I process. Nostr event objects use a similar method; however, by using N-Quads [1] with semantic meaning vs. whatever the hell we come up with later ("other stuff"=os from n.o.s.t.r.), I get some TBL W3C magic right up front in the data architecture. Unlike TBL magic, I'm at the logical layer, not lower, so it doesn't matter how the heptads are transported or assembled. The superpower of Nostr is that these assertions can be assembled into almost anything. I'm not sure the Nostr "experts" "building the next internet" [2] exactly understand where that power comes from or how it is related to N-Quads, but, frankly, you can lead a horse to water, but you can't make it drink. Everybody is comfortable in their world view, right? I'm not knocking the power of signed JSON with fully distributed identity, but it could be so much more if you design a better knowledge assertion. BUT, there is no reason somebody couldn't just spin up a NIP for the defined four elements in the content of an event object, or perhaps come up with graph, subject, predicate, and object tags or somesuch. It truly is remarkable what Nostr can do, despite the hubris and blindness. And, TBF, the entire dev world is on the same track. Triples are just too hard to grasp for most [3]. KVPs FTW is the battle cry. Quads? With fully distributed identity, provenance and timestamps? 🤯 What would B̶r̶i̶a̶n̶ ̶B̶o̶i̶t̶a̶n̶o̶ OpenClaw do? Our new savior. Now, the fabulous thing is that I can just point to the ongoing Nostr dev work if people want to extend my dead simple ideas. They have worked through a world of extensibility aspects in the NIPs that inform and explore how a collection of assertions can come together. And, I've said it before, but I learned extensively through Nostr examples. Despite bristling at their hubris in [2], and lack of historical understanding and nuance of what the Internet is, I am grateful (seriously) for what I've learned from their work. And, also, I attack TBL a wee bit, too, for not making the entire knowledg graph flexible and logical right up front. Remember when he complained that URIs should be forever? Barry Smith will chide my scruffy ontology, as will most academics, so I'll get mine as well... I just won't likely know about it if it ever does happen.
[1] https://www.w3.org/TR/n-quads/
[2] https://web.archive.org/web/20260629061645/https://nostrhub.io/
[3] https://web.archive.org/web/20230330092653/http://microformats.org/wiki/triples
2026-07-05
I'm at a design juncture. Do I keep the heptads in the HTML, or do I wrap them in a PNG? PNGs have an advantage as far as scraping and other abuse. Once the bots find parsable text, they keep downloading forever (years). I'm ingesting into IndexedDB for offline use already.
2026-07-05
The heptads for my journal edge case end up taking only 2.3MB in PNG form. These are 6.5MB uncompressed in JSON form. This includes signatures for each heptad. If I use a key of H7 in IndexedDB, it should still be painless to collaborate. Next step is to see what page load time is. I want < .5S.
2026-07-05
I'll run with this and see where it ends up: graphology, lib-upng, and showdown w/ full heptads in the single PNG w/ ability to export locally to catch the libraries w/o needing fetch, so you can just open up the single HTML page in #offlinefirst mode. All heptads cumulative in IndexedDB w/ export.
2026-07-05
When I get that feeling that everything I've worked on since 1986 leads to what I'm doing in the moment, including almost every weird rabbit hole, and it is *amazing*, I need to check myself. This is likely self deception and brain-must-find-pattern. I'm running my trace, and it still seems true.
2026-07-05
Now... luckily I have my journal going back to 1990, so I really can trace my ideas and see where I've circled around. Also, I have dev stubs from my software archives where I built up to something and tried something else. I can see how I picked back up later when I had the skills to proceed.
2026-07-06
I woke up and had the urge to strip out graphologyjs, and process heptads in memory for page rendering on the client app as needed. Alternating between proper graph databases, though, has helped my data model/schema. If Charles Peirce had a computer/JS, it would help reveal the nature of triples.
2026-07-06
The root node, attributes, instances, and relations are all distinct ideas that show up in code, particularly when you try and minimize. As an example, an attribute key is unique, but a relation is not. In another life, I would **study** Michael K Bergman's *A Knowledge Representation Practionary*.
2026-07-06
I added terser to my rollup bundle, and the PNG went from 2306207 bytes to 2296101. I'm removing terser minification. It really is surprising how much you get for free with PNG deflate. https://www.w3.org/TR/png/
2026-07-07
The code is **tight**. I can both load and process the journal heptads in less than .5S. This is for a journal that is 1000+ pages in a PDF w/ US letter size pages, so it is significant. I want to see if I can use intersection observer to constrain the render somehow for single page performance.
2026-07-07
The more I work with this, the more convinced I am that the flexible root schema combined with meaningless nodes that assume meaning in local code is the way. It seems to me that the OWL/BFO/RDFS form of universal ontology is a mistake. The effectiveness of modern LLMs/AI also show this.
2026-07-07
LLMs/AI are effective because they efficiently crank on existing stores without needing human analysis. The mistake of BFO and W3C is assuming a unified schema can be built, maintained, and applied at velocity. My heptad ideas are like Peirce's Monad;however, I *assume shifting human* perspective.
2026-07-07
An overall schema built by Barry Smith and similar via BFO for NASA, or massive GPU transforms on gathered data, assumes a central authority [1]. This can be collaborative (human genome project) or corporate. I think both are making a similar mistake.
[1] https://philpapers.org/archive/SMIOFS.pdf
2026-07-07
My criticism of an overall knowledge schema, preferring adaptive analysis in the present with extremely simple schemas and limber tools with a one-day ramp-up, should not be interpreted as scorn. BFO applications are an extensibility proof. Like the individual, corporate, and government resources used for WWW, MDN, SVG, JavaScript, ARPANET, GNU, Linux, Mike Bostock's D3, etc., all of this can be used to initiate #localfirst, in-the-moment, flexible, *even tactical* knowledge efforts.
2026-07-09
I was able to turn 11299 heptads into a fully functioning interactive journal reader in 46 lines of code. Next up, I'll publish the journal and code and create a video presentation. This year is the 40th anniversary of the two visions/meditations that started this journey ( which is in my journal).
2026-07-09
My guess is I've written 100 different personal journal programs. I am quite familiar with the kinds of things I like to see in a journal, and I have entries going back to 1990 when I was using an IBM 5150 and WordPerfect. My first GUI version was in 1994. It is a good fit for a knowledge graph.
2026-07-09
I had a paper journal from 1985 until 1987. Some was lost. Some I burned. I kept a journal for awhile on a Tandy CoCo running OS-9. That, too, is gone. I deleted a few entries since 1990, but for the most part, everything I've written since then is saved in electronic form.
2026-07-09
The 46 lines of code I'm using are all native JavaScript supported by major browsers. I am not using any libraries for the interactive reader. I'm not cheating with the heptads, either. They are logically N-Quads plus a timestamp, public key, and signature. I assemble these into the journal.
2026-07-09
I finished up the journal demo, recorded a vid and posted. That was a huge push. I need to back off a little bit. I'll break down the code from MCJ and include in https://hept.app in the coming week, but my RPM will lower. (BTW, RPM=Randle P McMurphy. Kesey meant to do that.)
2026-07-10
"Given the choice between the hard labor of self-governance and the warm assurance that someone competent is handling things, we hand over the keys. This is simply an observation so reliable that entire industries have been built on it."
https://www.owenmcgrann.com/p/nobody-expects-the-spanish-inquisition
2026-07-10
I designed the heptapp icon so that time was in the center. This makes sense. The other heptad elements revolve around time in a quickly changing, collaborative knowledge effort. I used Pault Tol's "Vibrant qualitative colour scheme", which has 7 colors that are "distinct for all people, including colour-blind readers,distinct from black and white, distinct on screen and paper, matching well together." [1]. I noticed the logo has the I, T, and E elements are across the center, left to right. This makes Nostr sense, as Nost has Identity, Time, and Endorsement (signature) elements. The other event object content is in the form of key-value pairs. Kind is an attribute, and Tags are a series of attributes against the original event content, so they aren't the same as G, S, P, O, which sets up the "ether" nodes [2]. In general, this is the same kind of cognitive jump around triples vs. key-value pairs that gets devs all confused [3]. We need to "fuck it, ship it!" [4]. We don't care that the magic of the WWW came from triples. If triples form a knowledge graph. N-quads form a hyper knowledge graph, and I, T, E show integrity and provenance over time. < Can't we just put attributes on the page instead, the chorus chants. > Also, I just noticed that Paul Tol has a similar favicon, but he didn't go for vibrant [5].
[1] https://sronpersonalpages.nl/~pault/
[2] https://youtu.be/sEoDkj4sBWQ
[3] https://microformats.org/wiki/triples
[4] https://web.archive.org/web/20150514145755/https://opbeat.com/blog/posts/fuck-it-ship-it/
[5] https://sronpersonalpages.nl/~pault/images/favicon.svg
2026-07-11
Bob's heptads are signed with a private key they control, as are Alice's. This means that #Ed25519 , #secp256r1, or any other can be intermixed. I use an attribute of `sig_algo` on G to indicate this. Similar to `has_root` and `label` attributes, this just sets up the broader meaning. An excellent application for this would be MQTT mTLS. Because the WWW mixed physical nodes, it is more difficult to do this, but G is logical, so the link is simply an attribute Bob can set on Alice's G.
2026-07-11
Another advantage to a logical G vs. mixing, is that references work through time. If `sig_algo` is switched out for #quantumresistance, the timestamp of the switch is captured in the history of the G element. Bob can still use Alice's logical maps just fine by a processing/visualization process that switches out the algo at, say, "20260709T041855266Z".
2026-07-11
I still need to write up the Journal portion, which I talked about in this video:
https://youtu.be/sEoDkj4sBWQ
After that I need to spend time explaining what it means to be "dimensionless dots in aether", and how there is no meaning for most of the dots until attributes and relations are assigned.