Don't allow setting arbitrary PrevID for records about go-threads

[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.

[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.