carsonfarmer

## Alternatives While the above proposed role-based access control provides an intuitive and reasonably standard access control framework, it is not the only option. In a decentralized system such as...

## Log reuse This wasn't mentioned in the above description, but is relevant here. There is nothing in the above formulation _or_ the existing Threads setup that would preclude peers...

## Repurposing Thread `Variant` In the above discussion, it was suggested that the `variant` varint could be removed in favour of assuming all Threads have an ACL (even a default...

## Easier Tracking Based on some comments above and a discussion IRL, it might be useful to encode the ACL information (or just the Thread ID) into the first new...

> Idea: We could allow setting an arbitrary nonce. It sounds more like a possible replacement to relying on time since the client could do a randomized sleep to indirectly...

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

No, not a local first issue here. But it could be related to this: https://github.com/textileio/js-textile/issues/1022

In both cases though, the results from the remote go-threads daemon are being reported, so this could be a) a issue with the query/where clause, or something funny b) with...

Just to update this issue, the issue referenced elsewhere (js-textile) indicates that: > If even a single document in the threadDB doesn't have the specific key that you are querying...

This fixes some linter nits, but it also fixes some potential import errors in the browser builds. The regression test should help make sure we don't run into issues in...