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.
- 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.
- 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.