Removing (mandatory?) timestamps

In a few threads recently people have suggested that logging timestamps on a message may be a problem squatconf-feedback traveler-control-of-info-release

In this thread I will discuss the practical implications of timestamps.

• clients are currently programmed to demand timestamps that monotonically increase within a feed. clients will reject a new message that does not have acceptable timestamps.
• timestamps are not particularly reliable this post had a timestamp 12 hours ahead

Removing timestamps

Removing would be a breaking change to feeds, and timestamps would be a pretty small thing, so i'd be reluctant to do that without also fixing other stuff. (this would also be bundled with fixing the encoding - turns out node@<6 used binary encoding as default for hashes of strings, instead of utf8, which gives a different hash for non-ascii strings)

resisting timing attacks

The main reason for removing timestamps would be to resist timing attacks, say, to figure out who is communicating with who. However, removing timestamps isn't enough to show there isn't information available through timing, to show we can resist this, we need to actually make timing models and timing attacks, and then resist those.

lie about timestamps

Timestamps only have to be monotonically increasing. instead of removing timestamps, you could have your timestamps increase by 1 ms each post. This would still be compatible with current ssb, but wouldn't otherwise tell you much. But that still wouldn't give us the ability to say that we don't have timing attacks.

Uses of timestamps

I think that timestamps are fairly useful, I often look at the time to see if that message is from today, etc, to interpret someone's post, knowing when they created it is very valuable context...

detecting sybils

I should also mention why I originally included timestamps, my main motivation is because I hoped we could use them for sybil detection, again, like timing attacks, really showing this to be true would require some model building that hasn't been done yet, but the basic idea would be to take replies as proof that message preceded your message. If I trust my own timestamps, and I reply to a message that you just posted, it's like I signed your timestamp. If we had a volley of replies back and forth, we'd know that at least in those instances timestamps where roughly correct. However, if someone generated a bunch of sock puppets, and tried to make them look old by having them post lots of messages with old timestamps, you'd see there wasn't an old path to them from someone you know into the sybils, there might a recent message though. basically, you could estimate how old those messages really where.

my thinking about removing timestamps was less about security and more about that timestamps are relic from older systems. I just wanted to see (and think about) what cipherspace looks like when detach it from geospace. Time in cipherspace be the causality derived from a hash DAG (a message in back and forth volley form a dag). But I don't know how use that would be... just maybe fun though :)

@keks I also think about ssb this way. it's not about being the most secure possible thing, it's about being a flexible thing that can do public, and can do quite private, and you can use to bootstrap truly private.

I guess you could take out the timestamps and indeed use some other signal.

I'd be okay with removing timestamps - but it might be some work to figure out the best way to do that.

Thanks for the write-up @Dominic . I don't think it's worth removing them given it's not clear what the benefit would be.

Thinking about posting private messages to ones self reminds me of how DNA is - there's a massive amount of 'non-coding' DNA in our body. Some of it seems to have expression regulation function, other parts of it just seem to form buffer which makes it less likely for the chain to be corrupted - because point mutations (corruptions) are more likely to happen in non-coding areas ...

Maybe there's a plugin which just sprinkles private messages in response to random message arrivals... and maybe we could also store useful info in those ... like I could cue up my dotfiles / config files to be regularly posted to myself as text in those messages...

@mixmix yes, there is definitely potential for resisting timing attacks using methods probably similar to those you describe, but making the claim "we resist timing attacks" is a serious thing, this would entail some serious research. A half-assed attempt would only damage our credibility and may not prevent timing attacks.

that said, I that is an interesting possibilty, but just if it's worth doing, it's worth doing right.

since it's on my mind, another possible way to resist timing attacks would be to queue up messages to send out at a pre-scheduled time.

It would simplify the API so it doesn't operate with both sequence numbers and timestamps so I'm all for removing it and letting application add it if they deem it useful.

to @Dominic

There are better options (by their nature/architecture) if you want really secure messaging.

If you want a great (usable) decentralized social network, I do not know of any better options than patchwork.

Messaging is a much more crowded market, and I would argue that one-to-many software depends more heavily on network effect than one-to-one software. I have four or five messaging apps on my phone(s), but I only post messages or participate in threads on patchwork.

Timestamps are a feature that I think most potential users would expect. I have noticed that I receive new messages over patchwork that date back to some time in 2015. It's worth knowing whether a conversation is ongoing, in most cases.

Protocols influence the way people use platforms, and removing timestamps from the UI could tend towards people responding to conversations which had died out weeks, months, or years before.

but idk

I'm imagining a new user joining the network and having no context about when a thread was last active.

....and yes, of course I'm a time lord.

removing timestamps from the UI could tend towards people responding to conversations which had died out weeks, months, or years before.

actually I think that could be cool. it could lead to some a But new people could have new insight in old conversations.

Indeed! I'm also more interested in it for that purpose than for security reasons.

I just expect that if timestamps were removed, then people who adopt patchwork in the future would probably end up requesting the feature (not knowing that it had been removed, or why).

Personally, I think I'd be ok with them being gone, though.

Clients could infer a window in which the message must have been posted anyway, assuming they'd participated in a thread at some point and knew when they had posted.

UX and crypto are hard to balance, but it's a really interesting problem space.

When we removed timestamps, you could still have timestamps inside messages, they'd just be shifted to the optional content, rather than a mandatory field. Mind you, that does mean you could get bounds for the time of a private message, because you know it's before whatever timestamped message was later in the chain.