to use with in_response_to as topics diverge perhaps?
We’ll see what @riddim reports on the Telegram msg structure and what metadata that uses.
1 Like
=D funny - I had the same thought and for just one user I’ve no doubt this is the way to do it =D but since there’s at least 2 people in a convo (possibly bots/automated messages as additional participants or representing one of the friends) there’s definitely the risk of collisions as time proceeds.
One resolution could be to have a rule that neo only is allowed to use odd time stamps and rid gets the even ones xD - that could be good enough
if you add a bot to the mix you have registered chat partners with IDs and same systematic just fewer allowed slots the more partners there are.
1 Like
I think in the end you will want each user to record their own copy of the conversation, that way one user cannot stuff up the archive by modding the code so that they can delete or modify the archive while it is being built.
1 Like
Hmm - yes
The issue here is that I’d need to store the datamap somewhere too (doesn’t fit into graphEntries) and we have 2 different chat participants…
My line of thinking was the following:
2 participants - 2 outbox pads == 8mb max messages but filling up with fluctuations on both sides.
Chat history could be a chain of graphEntries that point to single chunks. Chunks have AES encrypted content with ~3.5mb messages (from both outboxes in chronological order) - the first to persist those messages adds a snapshot message to his outbox to allow for easier syncing/deduplication of history
1 Like
One partner could have a ‘vanishing history’ plugin that removes all his outbox messages older than a few minutes and therefore it will never contain reasonable history when trying to persist the chat nonetheless … But I guess that’s just how it is… People are free to try and avoid any persisting…
(The other side then could try to use a capture-friend-history plugin to record without purging the old messages… Etc etc)
3 Likes
Each one is running their own copies, so should not be an issue. Each one looks after their own housekeeping
The datamaps can be held in 3 scratchpads (12MB buffer - again) that gets added to until it will exceed 12MB and then you write that to immutable with self encryption and that datamap is the first datamap in the 3 scratchpad buffer for datamaps.
So its a link list
As to the time to get to the first one, its not an issue as you are unlikely to want to access the older messages between you and oldmate more often that newer ones.
And if one partner doesn’t wish to record their convo then they don’t
But as to preventing the other from recording, then you’ve lost that battle before you start since they can record the convo other ways. Once you send the message you lose control as to how far it will travel if the other party wishes to reveal them.
Remember KISS, just record the convo in a way it can be looked back over without all the permissions stuff that can be bypassed anyhow.
3 Likes
=D you’re right ofc but I think my systematic with just using a linked list of singled chunks is 1. Persistet more often => reduces likelihood for Scratchpad state glitches and 2. significantly simpler than the structure with multiple buffer pads and self encryption in the mix =D
2 Likes
The reason i favour Self encryption is that it provides greater protection because people have to have more than just one record when trying to break the encryption.
That is all
5 Likes
just for the record … I have a first early version with an offline outbox; but (especially with a list of friends) the current implementation is pretty ruthless in firing a lot of parallel requests … that’s just too load-heavy (especially on startup); I need to rethink the flow and do start with a different strategy again to make it a bit lighter I think before I can release anything to others
some patience required but we’ll get there 
7 Likes
Short thread of feature requests for secure chat that may be of interest:
7 Likes
Quite distressed at this
It’s OK @scottefc86 I promise not to demand ALL the beer you owe me. Well not right away.
4 Likes
I’ll sort it tonight, got to restart all my nodes one of the kids thought it was a good idea to turn them all off today 
4 Likes
Hmhmm - is the network trying prevent us from celebrating too early again? 
On ryyn some strange network behaviour has been observed right now too it seems
1 Like
It may not be that, it is only what at the moment stands out when looking at the logs and trying to understand what that was.
Out of maybe 100 automated runs on network today, running right now as well, there has been absolutely no sign of such issue (or any at all beyond quite slow creation).
But most of those ran several hours ago. I will run a bunch back to back now to get an updated picture.
2 Likes
could be me how do i make sure everything is up to date?
edit: actually i think i am
scott@s00:~$ ant --version
Autonomi Client v0.4.6
Network version: ant/1.0/1
Package version: 2025.9.1.2
Git info: stable / c3dbf09 / 2025-09-03
1 Like
Well
I guess Ideally you would do a
git clone https://codeberg.org/riddim/dweb.git dweb_rid
cd dweb_rid
cargo build --release
./target/release/dweb serve
To build and run the latest version from my branch that works with the latest autonomi libs
(you obviously need to install rustup before to be able to compile and run rust code)
When it’s serving a dweb open friends should do the trick
2 Likes
Yeah but the important thing is to have a current version of dweb.
Not as up to date as my branch but pretty good too (and probably working too) is:
2 Likes
yeah obviously 
yeah done that i’m actually learning some of this stuff 
4 Likes
Haha - sorry xD… I guess bundling friends with dweb for Desktop would be something to consider too 
I need to investigate if tauri can pull self updates directly from autonomi too 
3 Likes