You might want to check out TMail21 ( https://tmail21.com ). It is thread (topic)-oriented. It also adds shared (versioned) facts to threads which opens up an interesting set of use cases.
Actually we use React+mobx on both our web and RN stacks and it's been great. What we really like is that it is simple and extremely performant since in most cases it automatically updates only the React components that need to be re-rendered based on the state that's been modified.
We jumped directly from a flux-like state management to mobx (skipping Redux) and the development time has gone down significantly as well.
Sure. Hyperledger Fabric 1.0 has the option of "Channels" to limit viewership rights. In particular it restricts rights to a subset of the community. For example, you may have a 1000 parties in the community, but a particular channel may have only three (say A, B and C).
Now, if one takes a Supply Chain example (a domain I'm quite familiar with), most transactions cannot be restricted to just parties A, B and C. Some will involve A, B and D and some will involve B, C and F etc. So, it is difficult to come up with a suitable Channel membership model.
Even if the transaction is between A, B and C often the view rights are not symmetric. For example in a drop ship case where A is the Buyer, B is the seller and C is the fulfiller, the price attribute may need to be visible between A and B but not C. This is not possible with the Channel approach.
So this particular type of hard partitioning only works for the simplest Supply Chain examples.
Another type of hard partition is to partition by Transaction. But this involves issues such as synchronization between transactions. This becomes an off-chain concern with major consistency issues.
The other major issue with Blockchain is that "all nodes can see everything". This is theoretically a problem with distributed databases as well. However, in the case of distributed databases, the database nodes that can "see everything" are not the end user, whereas, in Blockchain because the nodes are untrusted, one must assume that the end user can see the entire Blockchain state.
This limits the number of use-cases tremendously to those where "everyone-can-see-everything" is an acceptable tradeoff.
There are several ways around this.
1) Zero Knowledge Proofs. But these are highly specialized and resource intensive. To my knowledge we don't have these for generalized Smart Contracts.
2) Split the overall state into Channels, Subledgers etc. with narrower "viewing rights". But again this typically involves an application compromise.
3) Encrypt or cryptographically hash portions of the state. But by definition, this portion of the state cannot be acted upon by smart contracts.
4) Use frameworks like Microsoft's recently released CoCo Framework which relies on Hardware Trusted Execution Environments (TEE). The issue here is that a compromise of a single TEE negates the whole scheme.
In my opinion the privacy characteristics of Blockchain are a critical factor that needs to be taken into account while deciding on the suitability of Blockchai for an application.
I don't believe that one should try to create a single tool that covers both synchronous and asynchronous. Their UX is too different.
It seems to me a better idea to create an asynchronous deep collaboration tool and integrate it with synchronous tools like Slack.
The bigger question to me is what should an asynchronous deep collaboration tool do (if anything) beyond first-class threads.
In my mind the opportunity lies on three dimensions
1) Bringing updatable content and structure to threads. This makes threads vastly more useful for real collaboration (not just communication).
2) Making "catchup" much more efficient as this is the main problem with email.
If you think of one of the most successful asynchronous collaboration approaches, it's source control like git. The key thing that these tools to is make changes "diffable". That allows users to work at completely different points in time and still easily "catchup" with what's changed.
3) Allow regular users to easily convert unstructured one-off threads to semi-structured template threads. This naturally and gently moves teams to greater process-orientation.
These are some great points. You might want to check out https://tmail21.com. We built this around what we called Deep Collaboration (a riff on Deep Work).
We built it to be Thread First AND have a thread-first inbox as well.
However, more importantly we realized that just thread-first is not sufficient. We saw three major problems with synchronous solutions like Slack and asynchronous solutions like email.
1) Lack of support for updatable content
2) Lack of support for easily moving from unstructured to structured content.
3) Difficulty catching up
So we added the notion of Updateable "Sections" to threads (in addition to conventional attachments).
These "Sections" come in various types, some of which lend themselves to making your thread structured.
1) Text
2) Form (structured)
3) Task List
4) Checklist (process)
5) Word, Excel, Powerpoint
etc.
This allows one to create threads that have structured content. However, this still doesn't solve the "one-off" problem you described. So, we made it easy to take any thread and make it a "Template" that can be easily instantiated. This allows one to naturally to evolve towards lightweight processes starting from regular threads.
For example, here is one of the "industry solutions" pages which gives ideas for structured threads in a particular industry (in this case Manufacturing and Logistics)
Lastly for the "difficulty catching up" problem, we took inspiration from the way git et al are built and decided to make "diffs" central to the catchup metaphor. We're talking not only diffs for Text, but also for Task Lists, Grids, Checklists, Forms and other "Sections".
We hope to make communication and collaboration significantly more productive. Would love to get any HN feedback.
ps) We integrate with Slack to marry their synchronous model with our asynchronous model.
You might want to consider a deep collaboration tool (specifically built for asynchronous communication) like TMail21 (https://tmail21.com) . Deep Collaboration makes Deep Work possible.
For more on Deep Work, you can check out Cal Newport's book by the same name. (http://calnewport.com/books/deep-work/ ). It's a great read and definitely makes one rethink productivity.
Yes, but the resulting object is not a "List" and hence would not inter-operate with any function that took a List as input.
In essence if the original object implements a List _interface_, then the new one should as well. If you do all of this, then you've essentially implemented immutability and structural sharing. But then you have to do this for 10 other Collection types as well.
Now, you could do all this, but I could do it as well and do it differently. Then my function which took MyList as argument would not interoperate with your function that wants to pass YourList as argument.
Something as fundamental as an (immutable) collection needs to be standardized so that all functions can take these and return them and thus compose easily.
This is the case with languages that implement immutability like Elixir, Haskell etc.
This needs to be built into the language or somehow standardized by the community.
With lack of standardization of immutable collections, there would be lots of different ways that libraries would implement immutability. This would result in losing one of the main benefits of functional programming (i.e. awesome composability).
"Read-only" would not implement structural sharing.
Consider the situation where you had a linked list with 10,000
elements and you wanted to return a new list with one new element added to the 'head' of the list. With "read-only" you would literally have to make a new linked list with 10,001 elements which would kill performance.
While semantically correct, immutability via deep-copying is very impractical. So, immutability (of Collections in particular) needs to be implemented via structural sharing of elements.
In the above example, with structural sharing, the new list would have the new element and inside would point to the old 10,000 element list but the whole 'structure' would appear to you as just a normal list.
For immutability to be practical one would need to implement structural sharing in their collections otherwise copying would be prohibitively expensive.
What about immutability? A key part of functional programming is using immutable structures to avoid side effects.
My understanding is that Swift has these to some extent ("let" vs "var", structs being immutable etc). And since Kotlin is built on JVM compatibility I _assume_ that Kotlin does not support an immutable style of programming. Maybe someone here has more clarity on this.
Agreed that all of these can be used asynchronously. However, I would refer to these as "incidentally-asynchronous", in the sense that their design goals were not primarily to be asynchronous (and hence support "Deep Work").
The major determinant of asynchronous deep collaboration efficiency is number of "cycles-to-outcome". (where a cycle is roughly a request/response loop).
Email because of its lack of shared state collaboration generates lots of extra cycles because of confusion on shared state (i.e. attachment nightmare).
Conversely, something like online document collaboration supports shared state collaboration, but is really poor at "what happened". For all but the smallest of documents this leads to compounding "implicit document rot" on every iteration. Alternatively, it leads to ever increasing time to "catchup" once again vastly expanding cycles-to-outcome.
Neither is good with accountability (something that issue trackers are good with). Lack of accountability is another driver of increasing cycles-to-outcome.
A deep collaboration solution that enables Deep Work could be designed from first principles based on minimizing cycles-to-outcome.
Ever increasing distraction and "real-time" communication and collaboration are reaching a point of diminishing returns and actually decreasing our productivity.
The book Deep Work, by Cal Newport is a start on identifying the problem and a possible solution (i.e. isolate yourself for stretches of time to accomplish Deep Work).
Unfortunately, we live in a world where collaboration is necessary. So, what's the solution?
One possibility is to come up with a collaboration solution that is built from the ground up to be asynchronous in nature. (Deep Collaboration as the enabler of Deep Work)
Such a solution would complement our real-time collaboration solutions.
Hope this does not come across as self-serving, but I think it is relevant to the discussion.
We have built a product around what we call "Deep Collaboration". Deep Collaboration is fundamentally asynchronous in nature. The term is derived from Cal Newport's book on Deep Work.
Deep Collaboration allows teams to collaborate asynchronously thus enabling Deep Work (which group chat basically kills). If you read his book (highly recommended btw) you will see how individuals (and organizations) can produce transformative results via Deep Work. Unfortunately, his solutions to actually obtaining the uninterrupted time required for Deep Work is unrealistic in today's collaborative environments.
The problem is that Slack is designed for synchronous communication. However there is a huge need for a collaboration tool that is designed for asynchronous communication.
Being synchronous all the time means that you have no time to concentrate on cognitively complex work which is necessary for adding lots of value to your organization. Cal Newport in his seminal book of the same name calls this Deep Work.
Deep Collaboration is our term for collaboration that is asynchronous in nature and allows Deep Work to happen in collaborative environments.
Https://tmail21.com is a platform designed around Deep Collaboration principles.