@bobhaugen

Creating a tag with a message id in it could be useful if you want to mirror the repo externally, so that a person who gets the repo from outside SSB can locate the repo update messages on SSB.

@alanz

And it is up to a user of the repo to merge in any changes anyone else may have done, in any of the other trees referring to the same repo, and then put a new message/hash out to show that it is approved

This is not the case in the current git-ssb implementation. Currently, pushing to git-ssb is like replying to a thread, and fetching from git-ssb is like fetching new messages in the thread since you last fetched.

@joeyh

A sha1 preimage attrack would be necessary for any stronger attack.
[...]
No idea what you mean with the message ids and dags and stuff.

Each push to git-ssb publishes a git-update message. A git-update message links to previous git-update messages, forming a DAG. Including a message id with a git sha1 increases the hashspace to make infeasible the preimage attack. To link to a git commit on ssb, abstractly, use the tuple (commit id, message id) where the message id is of a git-update ssb message that pushed that commit.

@ev

we should offer people a choice about whether they want to trust repo authors or everyone in their network.

Noted.