Initial Contact
This was a private message to KajMagnus I sent and he replied, and agreed to allow it in public on my site.
Could we be working toward the same thing?
Hey KajMagnus,
I've been using Talkyard as the foundation for a knowledge system I'm building called LOGOS — part of a broader software development framework I've been designing called NEXUS. LOGOS is the knowledge and communication hub of the whole thing, and Talkyard's typed topics and nesting were the closest fit I could find to what I actually need.
In the process of building on top of it, I've been systematically documenting Talkyard's limitations — not as complaints, but as requirements that will eventually drive LOGOS forward. Things like unlimited subcategory nesting (Unlimited subcategory nesting) and custom topic types with definable workflow states (No custom topic types or type-specific workflows). The full list is here: Talkyard Limitations
The methodology behind NEXUS is built on Event Modeling — a design-before-implementation approach where the entire system is modeled as a timeline of events before any code is written. Part of what I'll be doing as NEXUS matures is reverse-engineering Talkyard with it — not from the codebase, but from the outside: the screens, the UX behavior, how it actually works as a human using it. The artifact is an event model that describes what the system does, independent of implementation. Depending on which direction things go, that model either becomes the reference point for understanding what LOGOS needs to replicate and extend, or it becomes the foundation for evolving Talkyard itself. Either way the work overlaps heavily with your domain.
I want to be straight about where NEXUS actually is: it's still being defined and refined, not yet proven, and I work on it as a truck driver with limited and irregular availability. This is a long-term effort. A reference implementation — a real working app built entirely through NEXUS methodology — is still a ways off. I'm not pitching something that's ready. I'm planting a seed early because the question of which path makes sense is worth thinking about before the work gets deep.
That path question is the bigger thing I've been sitting with:
Path one: LOGOS becomes its own project, built on NEXUS methodology, with Talkyard as the current-state reference. I have full design authority — priorities, feature set, every decision.
Path two: my LOGOS requirements get contributed back into Talkyard itself. Some of what I need might align cleanly with where you want to take it. Some might not — but those could potentially be toggle-driven, where your defaults stay your defaults and my needs are opt-in. The real appeal of this path isn't avoiding work — it's the AGPL spirit of ideas, design, and effort flowing in multiple directions. Users who engage with the methodology become contributors. Support burden gets shared. Design ideas come from people actively using the system for serious purposes. That kind of collaboration compounds in ways a solo project doesn't.
The reason I'm raising this now rather than later: the design and modeling work involved in both paths covers enormous common ground. Doing it twice on parallel tracks — me modeling forum behavior for LOGOS, you working from your own understanding of Talkyard — is duplicated effort that benefits neither of us. If there's any interest in path two, the work is better done once, shared, and built on together.
Path two only works if you're genuinely open to that kind of outside involvement — not just bug fixes and small PRs, but someone wanting to influence the feature set and design direction. That's a real question and I don't assume the answer is yes. A lot of solo-built projects reasonably aren't structured for it.
One other thing worth mentioning: the way NEXUS handles contributions is different from most open source projects. The hard work is the design and the spec — once those are solid, generating a working codebase is almost a formality with AI-assisted implementation. Contributing wouldn't primarily mean writing code. It would mean producing a solid event model slice and spec. Anyone willing to do that work could drive a feature forward.
Not pitching anything formal — just curious whether any of this resonates and whether it's worth continuing a conversation.
NEXUS: NEXUS — Start Here: The Framework at the Center of Everything
LOGOS: LOGOS — Start Here: What It Is and Why It's Central to Everything
Either way — thanks for building Talkyard. The typed topics and nesting were decisive for me. I haven't found another forum that gets both right.
— Ivan
- P@ProxyKajMagnus
Hi Ivan, this is interesting. I just read: "The problem NEXUS solves", The problem NEXUS solves. What if I join your forum and reply to that topic? And other topics.
systematically documenting Talkyard's limitations [...] The full list is here: [...]
That sounds interesting :- ) Maybe I can reply over there
... NEXUS is built on Event Modeling ... The artifact is an event model
Is that a graph? Like shown here: https://eventmodeling.org/posts/what-is-event-modeling/
I work on it as a truck driver with limited and irregular availability
Interesting with such a different job. Can I ask, how did you end up both driving trucks and being interested in software? (I was a forklift truck driver during some summers long ago, btw)
Path two: my LOGOS requirements get contributed back into Talkyard itself. Some of what I need might align cleanly with where you want to take it
Looking quickly at the Talkyard Limitations, those are all things I would like to address / fix.
The problems have been that 1) some things have been complicated, compared to usefulness. Or that 2) there's many possible approaches, and I haven't been sure how to go about it. For example, workflows and different topic types. Different organizations might want very different things. But that's something we could talk about.
influence the feature set and design direction
It would be nice to talk about
The hard work is the design and the spec
Actually, i think there'll be few people who can do security focused code reviews, compared to how many can do design & spec. (Can't trust AIs to write secure & reliable code.) — That security design/code/review might always be a bottleneck.
almost a formality with AI-assisted implementation
I'm afraid that, and almost positive that, a big software project generated by AIs will collapse under its own weight, so to speak. AIs make poor design decisions and write silly security bugs; this gets "exponentially worse" with project size. (Is my impression.) Still, they are helpful tools of course :- )
The typed topics and nesting were decisive for me. I haven't found another forum that gets both right
Yes I think Talkyard has a good data structure :- ) With nesting, do you mean threaded discussions or sth else?
I'll read the NEXUS start-here and LOGOS start-here in a little while (in some days? Later this week?).
Thanks for the message and it'd be fun to discuss features & design together :- ) Even though sometimes it might take days or a week in between my replies, and I noticed you're sometimes short of time too.
- I@IvanTheGeek
That sounds interesting :- ) Maybe I can reply over there
Please do!
Is that a graph? Like shown here: https://eventmodeling.org/posts/what-is-event-modeling/
actually, Event Modeling as Adam prescribes is to model the information flow through a system using the business behavior. To use example data to show A path through the system, usually starting from a high level and filling in as needed. The problem is tooling so far. He has used Miro, which is tedious to me.
NEXUS is just my mental container for how software could be built. Been doing a BUNCH of chats with Claude and ChatGPT. Learning graph theory on the fly. My current mental model is that there is a base Nexus Graph, the Truth Graph, that has its set of nodes and edges with a set of base ontology. Then I create sub-graphs that are renaming the base ontology to match the domain and context and graph layers. So just ONE of those sub-graphs will be the Adam Event Modeling context. Event sourcing is being used, so all state changes are an immutable fact:NEXUS/Event:EM everything has its own View made just for it. I am currently planning to use git for event storage, with a commit for each new event. That give a time dimension and the ability to diff and have full history to fold over to get current state.
Expanding on that, the LOGOS is the information gathering, communication, and storage conceptual part. Talkyard is living in this area now, and there will be vectorDB and other things. The idea is to have all data be able to be facts and can be processed, analyzed, and inform. AI, which I group as CORTEX will be one or multiple models that help process and suggest. It will have a feedback cycle so it can be a local model, which will probably consult with the bigger ones like Claude and ChatGPT. Again, all chat available in LOGOS and can be processed and reviewed. LOGOS also could ingest emails, bug reports, user questions, discord channels, youtube comments, and of course forum contents. All become immutable facts in the system and can inform the modeling.Modeling will be ATLAS, most likely a Studio that has many tools, with model viewing and editing and creation being the primary focus. The main work would be done here to get the models correct so the specs are right.
Once the model pieces are approved, it can then feed spec to FORGE which can be thought of as a spec to source code to artifact compiler. Just recently, I think the plan here is to have AI help build the functions that transform the spec to source code. Then that code can be reviewed and modified, or more likely modify the rules the AI is using to make it more in line with what a dev wants. once the functional compiler is good and checked off by the dev, they get a reproducible and deterministic way to take a known and trackable spec, compile to source code, build the artifact. Again, all history stored in git and traceable and viewable.
PAXUS is the deploy and runtime manager and monitor that feeds runtime data back to LOGOS for reanalysis and surface improvements.So based on Adam's Event Modeling, just expanded and codified if I get it all worked out. The core idea is that everything reduces to a graph, which AI works wonders with, and is the Source off Truth (SoT). everything else is just trying to get data into the graph, or a interpretation/projection of the NEXUS truth graph.
When I am able to get it realized, this can be applied to other domains like video content creation, and even learning and support sites that uses all the data and summaries and can be used to create training courses or videos to post on youtube.
all sounds a lot of hand wavy and pie in the sky, but I have the vision and AI is allowing me to work it out. I focus on F# for code, been learning it since 2010, just I am not a coder, it is not the way my mind works. I have real issues on the command line too. But building software this way allows me to focus on the app and not the coding.
immutable software evolution
Actually, i think there'll be few people who can do security focused code reviews, compared to how many can do design & spec. (Can't trust AIs to write secure & reliable code.) — That security design/code/review might always be a bottleneck.
I think my functional spec compiler helps with this and there is already plans for a security/audit sub-graph as well. I am hoping that this can change bottleneck.
I'm afraid that, and almost positive that, a big software project generated by AIs will collapse under its own weight, so to speak. AIs make poor design decisions and write silly security bugs;
.nesting, do you mean threaded discussions
yes. also the add comments to blogs was a big plus. The topic types also.
I like said, still a lot of hand wavy and not a working set of info docs yet, but getting closer each working session.
- K@kajmagnus
I am currently planning to use git for event storage, with a commit for each new event. That give a time dimension and the ability to diff and have full history to fold over to get current state.
I was thinking like that long ago me too: Files + Git. A major problem with this is that then knowing what data you have, and data structure migrations become harder. (I think one is unlikely to find the right data structures on the 1st attempt.) But if you use Postgres tables and something like Sqlx, https://crates.io/crates/sqlx-cli, that's much less of a problem. About a time dimension: You can add timestamps to the SQL tables. (Don't know if you've thought about all this, or if were thinking about very different things)
AI, which I group as CORTEX will be one or multiple models that help process and suggest
Reminds me of this post yesterday at Hacker News:
LLM Wiki – example of an "idea file"
https://news.ycombinator.com/item?id=47640875He also uses AI to process and organize a database full of information, sort of.
LOGOS, CORTEX, ATLAS, and how they communicate with each other — You'll do AI assisted coding in F#? Nice language b.t.w. I used to really like Haskell :- )
Modeling will be ATLAS, ... to get the models correct so the specs are right.
These are some data structure models? Which are then being used / referred to in the specs? ATLAS is like a data structure design tool?
everything reduces to a graph, which AI works wonders with
Aha, so instead of an Abstract Syntax Tree, you'll have a "Specifications Tree"? (or graph)
build the functions that transform the spec to source code
I suspect that a spec that can be deterministically transformed to source code, will actually pretty much be source code itself. Maybe like a higher level programming language that's somewhat forgiving of typos.
once the functional compiler is good and checked off by the dev, they get a reproducible and deterministic way to take a known and trackable spec, compile to source code
Hmm but AIs aren't that deterministic? More like humans: unpredictable, do random silly things, I think.
When I am able to get it realized, this can be applied to other domains [...]
all sounds a lot of hand wavy and pie in the skyActually, what I'm thinking is that there's other people out there with not exactly the same, but similar ideas :- )
there is already plans for a security/audit sub-graph as well. I am hoping that this can change bottleneck
In some years, who knows :- ) Maybe some of the security people will focus on reviewing the specs instead of reviewing the generated code, because the AIs will be that good.
- I@IvanTheGeek
LOGOS, CORTEX, ATLAS are more conceptual that are contributed to by the various artifacts and systems. I hope to have this more presentable at some point when I have it actually coherent and demonstratable.
- IIn reply toIvanTheGeek⬆:@IvanTheGeek
Oh wow, thank you so much for your reply!
Would you be open to transferring this to either my forum or yours? I did a PM because, honesty, I have not done enough in the Talkyard forum to know if this would have been appropriate to post there.
My reason to do forum style is that this and ongoing feels like it would be helpful as documenting as the spark as later reference and data points (events) and kinda is an example of a major idea in my system/concept/vision and part of my "I try to do openly as much as is safe" ideal.We could do it as public or private, in yours (Talkyard) or mine (IvanTheGeek), what ever you might prefer. If not, we can continue here in PM.
[Edit]
Or maybe this type of stuff you prefer in github? I am not sure where you operate what yet. - PIn reply toIvanTheGeek⬆:@ProxyKajMagnus
Hi Ivan!
Would you be open to transferring this to either my forum or yours?
Yes I think so. You mean this PM? Changing it to a public topic here at Ty .io?
I thinks subsequent discussions about NEXUS and LOGOS fits better at your forum/website. And, when we decide that "This thing would be nice to add / fix in Talkyard", then we can create an issue here about that, and link to the underlying discussion at your forum.
helpful as documenting as the spark as later reference and data points (events) and kinda is an example of a major idea in my system/concept/vision and part of my "I try to do openly as much as is safe" ideal.
Ok :- )
Or maybe this type of stuff you prefer in github? I am not sure where you operate what yet.
I've actually disabled GitHub discussions and issues — I didn't like having the discussions split in 2 different places. Also, when an OSS project "owns" its own discussions & communication, it's more free (free as in a bird in the sky :- ))
(Reminds a bit of how you're thinking btw?)You don't happen to have a LinkedIn page or something?
(Sorry for the somewhat late reply. I've been doing bookkeeping & finishing the next major version / epoch, v1)
- I@IvanTheGeek
Also, when an OSS project "owns" its own discussions & communication, it's more free (free as in a bird in the sky :- ))
(Reminds a bit of how you're thinking btw?)yup, absolutely. 110%
You don't happen to have a LinkedIn page or something?
https://www.linkedin.com/in/ivanrainbolt/
but honestly, I got it for something for whatever reason, and really do not pay much attention to it.https://github.com/IvanTheGeek
If you have Signal: IvanTheGeek.55
Interesting with such a different job. Can I ask, how did you end up both driving trucks and being interested in software? (I was a forklift truck driver during some summers long ago, btw)
short answer: it pays the bills. You are the second person recently to express interest in how I got here. I think I will do an origin story topic. :) stay tuned. I have always been a geek, just not been able to pay the bills with it for a long time.
- K@kajmagnus
Ok :- ) Thanks for the links
an origin story topic
That sounds interesting
- I@IvanTheGeek
Yeah, seems to be growing in need. I will have to use AI to make all my ramblings into different versions and lengths so the viewer can decide how much and how deep they want to dig in. LoL
- IIn reply toIvanTheGeek⬆:@IvanTheGeek
FYI: I am creating questions as I encounter them. I plan to answer my own questions when I find the answer. This is for my own benefit and purposes, I do not expect you or anyone to answer them. :) Not that you couldn't, just expressing my reason for all the questions.
- KIn reply toIvanTheGeek⬆:@kajmagnus
Hello Ivan! I'll write more in a little while :- )
- KIn reply toIvanTheGeek⬆:@kajmagnus
Next: I guess I'll have a look at the other topics in this forum, and reply here and there,
Not now immediately but the nearest weeks
- IIn reply toIvanTheGeek⬆:@IvanTheGeek
All of your replies are valid. Yes, many are circling the same ideas and working towards solutions. I am trying to find one that works for me and meets MY expectations. That is really what NEXUS is, my concept and my solutions to allow me to actually focus on making solutions and the apps that I want. I have a hard time actually communicating an idea or vision I have to others. This is currently where AI like Claude and ChatGPT are really helping. They are allowing me to formalize and document what is in my head and imagination. Still very chaotic, but at least I am starting to get it workable.
The things is, once I get a tangible thing working, THEN others tend to be like "oh, that is awesome" and want to use it. So that is where I am trying to build the infrastructure so that I can build the real thing I want. Instead of searching 4 hours to get unstuck on a syntax issue, AI is able to produce a version, then I correct and change to get what I was trying to accomplish. For me, Event Modeling is the vehicle, I think the graphing of that model along with event sourcing is the path that will get me there. At least thats the mindset today. Tomorrow, might find something else. Using F# and the functional programming and related patterns along with strong typing, along with the dotnet being able to basically be ran everywhere, along with having Microsoft history, which is not so important of them being Microsoft but the users are so broad. I can use any C# libraries in my F#, might be some friction, but their library might be good. And broad range of libraries to boot. All works together to be a good fit for me.
I was working on modeling Event Modeling ironically and decided that I wanted this in F# code, and had Claude Code working it. It finished and gave me some feedback that by using the F# and the modeling I told it to do, that it discovered some real benefits to using the F# and what the compiler enforces. Just an interesting thing to me.
Your point about the spec being good enough to generate code might be the same as the source code. Sort of, just at a different abstraction. In the same way, this led me to:
https://chatgpt.com/share/69d5464e-7b60-8326-877f-16157408fba2
Are you using Scala more functionally or more OO? Just curious.
Once I have the framework to do the event modeling, I will make an event model of Talkyard that is event sourced. Then, it will make more sense of what I am trying to get to. It is entirely possible for you to work your current codebase and reference the event model and see where you need to code.
It is interesting also that over Easter we spent it at family. My brother in law was showing me his one file c++ card game that he has worked on. He was saying his hard it was to try and get it to to be visual. It is text based currently. I ran the ai over the code and asked for an event model. It gave a rough one, but was already telling me where there were unused functions, errors in logic, and other things. Looking at the event model those things where glaring. So I am using his little (well, like 1200 loc) as example for building my event modeling model and F# code. Confusing I know. But Lonny is very excited to see what his little game can get to. 😃
I have also figured out that I was trying to crane too much into talkyard. By writing most my stuff in MD as a "docs" site and then using mkdocs to make it a website it is working more like what I wanted. BUT, using the blog comments aspect of talkyard is the perfect solution and that was a major feature for selecting talkyard to begin with. So use the right tool for the right job realization.
Will keep ya posted.