AddThread without creating a log

[requilence]

Hey! I have a question to discuss.

Some background:
In anytype when you sign in to the existing account on a new device you generate the new libp2p identity and recover(AddThread) the rest of threads using the info in the derived ThreadsDB. Now imagine an account with 1000 threads, but 50% of them changes very rarely(with a high chance they may be never changed on some devices). As a result, if you did sign in many times in the past you will have a lot of empty useless thread logs.

So what we have:

1. Currently it is not possible to add an existing thread (using net.AddThread) with a ReadKey but without a Log.

   go-threads/net/net.go

   Lines 341 to 345 in 5d09258

   	if args.ThreadKey.CanRead() || args.LogKey != nil {
   	if _, err = n.createLog(id, args.LogKey, identity); err != nil {
   	return
   	}
   	}

2. As a result user needs to create an empty log even in case it has no plans to write some records there yet(or maybe even never)
3. Still, an empty-head log with valid addresses on a thread increases the chances other peers will be able to pull the rest of logs via your node
4. On the other side creating logs in a lazy mode can be the first step in preparation for read-write permissions and the ability to change these permissions in time. And we will probably need another way for read-only users to add their addresses to the thread
5. And last option, we can just follow the goal that go-threads outgoing/incoming requests should not linearly scale with a number of threads. This means grouping requests by peer IDs instead, which in turn means empty logs make no sense if we have non-empty logs of the same peers in other threads.

Should we allow AddThread without a log now or it's better to postpone this discussion after the read-write ACL?

[sanderpick]

Hi Roman! Great idea. I believe we used to lazy-create logs in the way you describe, but that behavior was changed for some reason. Sleuthing threw the commit history, I honestly can't remember why. I have a feeling it was related to using the a thread node from the JS client. Does this ring any bells @carsonfarmer ?

tl;dr, sounds like a good idea to add that back now.

[carsonfarmer]

Hmmm, I think it was something to do with our multi-tenant setup, and "joining" threads that were already locally available on the remote node? Either way, it seems like the constraint could be relaxed? But we will defs have to test this before deploying anything. I'll have to dig in to be sure. It might also have something to do with differentiating between a thread "owner" (the node owns the thread and has full private key support) vs thread "users" (only have a log, but the private key isn't available locally/on the node).