[yonrg]

This categorization seems to be based on one dimensional thinking (not in a bad way).

If you bring in more dimensions you end up with something like a taxonomy where an email contains a message and maybe also a todo or something else and may have more attributes around those identities. Then you can filter by those. I do not use that personally but I see there is no reason to define an email as a todo item.

Also, as an email is just a storage for data, you could (mis)use it as a storage backend for a file system (see fuse) or backup solution.

So an email can be everything you want.

[chris-orgmenta]

You end up with a graph. Entities are the nodes, and the entity-relationships are the edges.

An email is always a message, nothing more. Tasks, events etc. can be derived from it, but the email itself is not a task or event. This isn't arbitrary, these boundaries are clean as heck (again of course, with the 'IMO' caveat. I don't care to convert anyone here).

[ethanbond]

Very interesting model — what do you actually do with this conception? Do you have software that helps you reason about your inbox/rest of life this way?

[chris-orgmenta]

At the moment, personal stack only. React native web local + react query + async storage + supabase + etc.

If I pull up a contact 'MyClient' I can see every entity that's ever been related to it.

- What contacts (customers, employees, suppliers) it has.

- What locations (sites, warehouses, drop ship locations, digital locations) it has.

- What tasks (projects, todos) there are. I see 'service board implementation' which is an old project on 'Completed' status there right now, for example. And if I drill into that project, then I can in turn see every entity that was ever linked to it.

- What messages (emails, phone calls, etc). there are. Phone calls, SMS etc. are not integrated yet.

- Blueprints (e.g. 'Monthly vendor reconciliation 3rd day of every month'). auto rules not implemented yet, I'm manually clicking a 'load in template' button.

- Etc.

I can also view(/filter/etc.) by entity Status.

- 0. New

- 1. Respond (Something has changed, e.g. a customer has replied into it. Attention is needed).

- 2. Active <-- this position is not a hill I am prepared to die on. Personal preference.

- 3. Waiting (on external)

- 4. Hold (no action to take until specific date)

- 5. Evaluate (no further action needed apart from analysis+closure)

- 6. Cancelled

- 7. Complete

So everything actionable floats to the top, and everything non-actionable sinks to the bottom. When an entity becomes actionable, it then automatically floats to the top (e.g. 'EmployeeA was supposed to have provided reportX by now. Followup'.)

But basically, 2 clicks to create an entity. 3 moves to relate an entity to another entity. Automatic entity creation from different services into Supabase (Gmail, working on MSGraph, etc.), with server side triggers & functions to process and automate.

I can view the entity-relationship graph via 'displays' (not all implemented yet):

- Pods (drag and drop widget grid)

- Kanban

- Form

- Table

- Calendar

- Map

- Json

- CPA / Nodes

- etc.

So it's just a representation of my brain that saves a lot of time (especially in tracking things down) and augments my own abilities.

I am working on using this in a B2B product (an ERP for MSPs is the primary use case).

I consider every ticketing system, ITIL service board app, todo app, messaging system, Jira, PM application, ERP, etc... To be completely missing the big picture.

As soon as someone has implemented both a 'Customer' and a 'Supplier' table in a RDBMS, I think an opportunity has been missed and that we have not realised how refined relational db tech has become in the last 10 years. I consider us to need a generalist 'Hub' structure that other services interface with. Self hosting option vital. I have formal data structure training (relational database design, yes a lot of UML historically, set theory), consider this abstract level of the space to be slightly more objective than others do, and have the hubris to consider myself qualified. But, I know that I would not be able to convert everyone to my way of thinking - Nor do I have the time or the inclination. I just love thinking about data structures.

[chris-orgmenta]

Preempting possible 'wtf's: Yup, relational db. GraphQL also fine. Relational db will not necessary avoid n+1 problem. Equally, n+1 problem is OK in GraphQL (I don't consider it a deal breaker and support the tech inc. in context here). KV db tech not appropriate.

Security & Encryption on row/property level = possible but significant challenge to keep performant (But I suggest that it is feasible, even in 5+TB tables). Limited stress testing so far has had surprisingly good results. Due to atomic entity-relationship granularity, it makes selective role-access very powerful. The problem then becomes the shape of the graph (the structure itself - not the data - of the graph, if exposed, could imply information and is a huge security risk). The other major risk is dynamic querying.

Data should be siloed to the extreme. Added benefit of making hosting changes hot-swappable. Go self hosted in (almost)singleclick. each 'space' needs own tables (own schemas not really relevant for security). Also added benefit for performance. 'sharing' is 'opt-in' (with caveat/nuance for automation), and explicitly 'crosses the border' to go outside of a space. This is at the cost of inter-space queries, but that's a necessary loss. All current solutions on the market fail security sniff tests.

Very eager to get local LLM hooked up to my personal graph for natural language querying (I think my dataset+datastructure is the most appropriate I have ever seen, for this. AI totally outside of my wheelhouse though), but it won't bubble up to the top of priorities for a few months at least

[ethanbond]

This is super interesting, thanks for the detail! I bet the LLM experiment will be very interesting for you and I hope you share the results here on HN!

[chris-orgmenta]

Thanks! Appreciate the interest