Don't allow setting arbitrary PrevID for records

[merlinran]

Currently adding an arbitrary record is allowed (https://pkg.go.dev/github.com/textileio/go-threads@v1.0.2#readme-adding-a-thread-record) so I made the mistake of creating records using other logs' records as Prev in the testground test, and alas, the test passes sometimes, but causes all these problems of lock contention etc. So after clarifying w/ @sanderpick and @carsonfarmer it's pretty clear that when creating, a new record should only set the current log head as its Prev, because a log is just a chain of records created by the log's owner.

The simplest would be to remove the Prev field in the cbor.CreateRecordConfig, or, to avoid compatibility issues, override it and print a warning if it doesn't equal to the current head. In later stage we could probably have a better API which can get rid of AddRecord altogether.

[merlinran]

Well we can't remove the Prev field in the cbor.CreateRecordConfig because signing requires it. Guess we have to postpone to API change to have a log abstraction, for example, so we can call something like log.AppendRecord in an intuitive way.

[sanderpick]

Ah, makes sense. I was also wondering something related that @carsonfarmer may know about: Doesn't the threaddb js lib need to "batch" add records that are already chained? I believe that was the origin of the AddRecord API.

Instead of removing the API, we could probably fix the putRecords logic to enforce that either:

• The first entry's Prev in the chain is HEAD
• HEAD is somewhere in the chain

That should be enough to prevent creating orphaned chains.

[carsonfarmer]

Not at the moment @sanderpick, because the JS libs no longer operate at this lower level API (they did when we had a full JS node). You are indeed correct though, that AddRecord was required in JS-land so that remote peers (js-threads) could create Records and then push them to the "remote" (go-threads). We don't do this at the moment, but there is a future where a JSON-RPC wrapped AddRecord API could be used from JS-land again...

I guess TL;DR not a constraint for JS right now.