tmail21

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.

Hope this helps.

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.

agreed. Although have encountered most of these ideas before, the goo analogy (whether valid or not) made everything easier to relate to.

ps) Not a physicist.

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.

Not sure about the governance model of Kotlin. Hopefully it succeeds.

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.

Cool.

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.

Looks like there is some distinction between Mutable, Read-only View and Immutable.

According to this http://stackoverflow.com/questions/33727657/kotlin-and-immut... Kotlin does not support true immutability.

For immutability to be practical one would need to implement structural sharing in their collections otherwise copying would be prohibitively expensive.

This Java library seems to be trying to implement this. http://www.vavr.io/

Again, I am not saying that Kotlin does not support immutability, just trying to get to the bottom of the reality of it.

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.

How do you know for sure? :)

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.

If one absolutely wants real-time collaborative editing then the only (long-term) solution I see is something like a deep learning solution that continuously semantically analyzes the merged state for semantic errors. In a particular problem domain this might be 5-10 years out. In the general case, this starts to approach the level of difficulty of AGI and hence who knows when that'll happen :)

Some practical solutions are that the document starts out in a 'real-time collaborative editing' phase. After this phase is over, the document moves to a 'review' phase where the document is reviewed for semantic errors and those errors are fixed using a 'non-real-time' approach.

The only way I see at this time to avoid silent semantic errors in the first place are non-real-time approaches.

The best practices here are optimistic locking/leasing of "semantically-connected regions" (could be defined as a paragraph, document, multi-docset, worksheet, slide etc.) along with semantically useful diffs (diffs that are meaningful for an end user) for conflicts.

You could say that this is the approach taken by version control systems like git, where the semantically-connected region is the File/Document.

Semantically useful diffs for anything other than text documents is a non-trivial problem in itself. But is still more tractable than avoiding or detecting silent semantic errors with OT.

Yes, this problem could be mitigated somewhat by showing caret positions. But this method is very reliant on the users paying extremely close attention. It does not work at all when the silent semantic errors are caused by "far flung" edits, where you don't even see the other caret because it is "off screen" for you.

Asking users to resolve a conflict is not possible, because the whole idea of OT is to have no-conflict merges and would have no idea where the conflicts are.

It is fairly trivial to construct an example where editors are editing _different_ sentences and OT takes two locally semantically correct states and converges to a semantically incorrect (but grammatically correct) state.

I think OT and other "real-time" collaborative editors are practical if you are willing to (or your use case can) live with "silent semantic errors".

The greater the document "interconnectivity" (eg, paragraph A is semantically related to paragraph C), the greater the likelihood of having far-flung silent semantic errors.

For documents like spreadsheets this is very obvious because you start getting nonsensical results and (hopefully) errors very quickly. For Word-like documents, the errors are "silent" and thus much more insidious.

My point was that that is an element of OT which many users don't realize.

With regards to predictability, I would not call the results of OT predictable from a user's perspective. It is predictable in the narrow sense that for a sequence of arrival of operations AT THE SERVER it is predictable.

However, it is impossible for a user to predict how their local operations will interleave at the server with other users' local operations. For all practical purposes the converged result is unpredictable from the user's perspective.

The only property which one can confidently assert with OT is eventual consistency.

The basic problem with OT (and current "real-time" collaborative editing approaches) is that they can only achieve eventual consistency.

While this sounds great, eventual consistency DOES NOT mean semantic consistency. This rules it out for many applications where semantic correctness is important.

Even for simple text documents you can get eventually correct but semantically incorrect results.

For example, consider the sentence

"The car run well"

This has an obvious grammatical error.

Now imagine two collaborative editors.

Editor 1: Fixes this to

"The car runs well"

Editor 2: Fixes this to

"The car will run well"

Depending on the specific ordering of character inserts and deletes this could easily converge to

"The car will runs well"

Obviously this statement is both grammatically incorrect as well as semantically ambiguous. (However, both editors see the same result and it is hence eventually consistent). Worse, OT collaborative editing will silently do this and carry on.

Now, for non-critical text where errors like this are ok, this may not be a big problem. But imagine contracts or white papers, or trying to use this on something like a spreadsheet where semantic correctness is critical and one can see why the current scope of collaborative "real-time" editing is very limited.

In general current "real-time" editing approaches like OT are outright dangerous.

The reason this is happening more and more is because teams are bumping up against the limits of synchronous communication. Especially when teams get large, and everyone has an expectation of immediate response the whole thing falls apart.

What's really needed is a communication platform that is geared towards asynchronous communication but integrated deeply with chat apps like Slack, Hipchat etc.

I wrote a follow up to both your article and the original one. https://medium.com/@rnotani/the-different-frustrations-of-sl...

Here is a relevant quote from the article.

"In my opinion both of these posts get it partly right. Both of these articles also have as a subtext an implicit or explicit comparison with email. Both, Slack and email tend towards “communication overload”. However, the generic description of “communication overload” obscures the very different type of overload created by these two technologies. Understanding this distinction also leads us to a possible solution.

Check out TMail21 ("Power Threads for Teams". It is explicitly designed as an asynchronous communication platform. Furthermore, it is being integrated into all of the chat services like Slack, Hipchat etc. to avoid balkanization between chat and asynchronous communication.

The key is to realize that Slack et al are really good for synchronous communication (users need to be present simultaneously to really be effective). EMail was designed for asynchronous (reply later) communication. The expectation that everything can be done synchronously is unrealistic. The reasons for this are users spread across multiple timezones, unavailability of a party, the need for some thought and consideration etc. Unfortunately, email, as we all know has a lot of flaws.

An ideal comprehensive communication infrastructure would be one that encompasses both synchronous (Slack, Hipchat etc.) and asynchronous modes but in such a way that one doesn't create two disjoint islands as is the case now between chat and email.

TMail21 (https://tmail21.com) is an asynchronous communications platform that is designed (amongst other things) to integrate with chat apps so the appropriate communication mode can be used at the appropriate time.

At the end of the day there is no silver bullet to the team communication and collaboration challenge. There are so many permutations and combinations of use cases. It's a matter of picking the right tool for the right job.

The other reasons why processes are not adopted is that most employees are not thinking in terms of 'processes'. Secondly typical process/BPM tools are geared towards I.T. rather than regular workers.

Both problems can be solved by gearing tools towards end-users rather than I.T. and allowing processes to emerge from lower-level constructs like (say) discussion threads that workers normally participate in. This would gently steer workers towards a process mindset.

I apologize if they came across as excessively commercial. I thought they were relevant to the discussion at hand. I will be more careful in the future.

Thanks for your insights bitcuration. I agree that email is flexible enough to do things like goal oriented discussions, but it is just so painful. The best one can do is fling attachments around and hope to get all the versioning right and avoid inadvertent branching.

TMail21 does other email-like things like transmitting files, notifications, full search etc.

It also does interesting things like giving every thread a unique tracking number, which allows it to be tied into the broader enterprise ecosystem. The idea is that just like the URL transformed the Internet (i.e. the web), Tracking numbers can transform 'email'. Now, TMails can be referred to from Chat, Voice, IM, Apps, Spreadsheets etc.

Another thing we do that is very hard to do in email is things like Certified Mail, Certified Forwards, Transactional Guarantees, Certified Diffs, Non-repudiable audit trails etc.

All of these capabilities are however means to an end to make TMail21 the first true BPM tool for regular business users (rather than for coders and 'process analysts)

You might want to consider TMail21 (https://tmail21.com). We just soft-launched a couple of weeks back. It is what we call a Lean BPM app.

The idea behind TMail21 is that is starts with Topic-Oriented Discussions and then allows a user to progress to Goal-oriented Discussions and finally to what we call Lean Processes.

TMail21 was designed to look and feel a lot like e-mail, so it feels instantly familiar to most business users.

Until now, traditional Business Process Management (BPM) has been a code-oriented solution not geared towards regular business users. TMail21 is definitively geared towards regular business users. We refer to this as Lean BPM and in fact have created a Lean BPM Manifesto https://tmail21.com/lean-bpm-manifesto/ to enumerate the principles of our approach.

I should also mention that Lean BPM and Project tools like Asana/Basecamp/Trello solve different problems. Some differences 1) The Process-to-project ratio in a typical work environment is very high (often 100:1). So there may be 10,000 process instances vs. 100 projects. So, obviously this calls for a very different interface. 2) Processes are really good for capturing recurring work patterns. In Lean BPM, patterns that repeat often can be easily institutionalized into Process Templates. 3) Unlike tools like Asana which are primarily orchestration tools, a key element of Process tools is capturing and evolving a meaningful process state.

These points are best illustrated with an example. Let's consider the example of a Blog Post. An organization may do hundreds of Blog Posts. These could be done as Projects, but are probably better done as Processes as they tend to have similar goals, process state and tasks.

So the Sections (Process State) of a Blog Post may contain a) Title Ideation - A text Section, to brainstorm titles b) Article Outline - A rough outline of the article c) The Actual Article - A text Section with the actual article d) Blog Form - A form Section with fields like Blog Title, Process State (CONTENT-CREATION-> OUTREACH-STARTED -> OUTREACH-ENDED), Blog link, Tweet link, Facebook Post link, Google+ post link, e) Planned Tweets - A text Section f) Hashtags and keywords - A text Section with hashtags and keywords that will be g) Influencer Outreach - A Grid Section with a list of influencers that will there will be outreach to. Each row will represent a single influencer and their outreach state h) Checklist - A checklist that lists the tasks required to complete this Process.

You are right. There is a mix of notifications and discussions with the mix varying between the two based on the nature of user's communication. In more collaborative scenarios, it may be 80%-20% discussion-notification. In other scenarios the ratio may be reversed.

On the pure notification front, we have friendly tracking numbers (so that notifications can be referred to from other places like spreadsheets, chat, apps, voice etc.). These tracking numbers look something like 124-1234-1234. We also support Certified Mail, Certified Forwards, Certified Read Acks etc.

Having said this, we currently support outbound notifications (from TMail to TMail/EMail). On the inbound side we support TMail to TMail. We do not currently support EMail to TMail notifications although we may add this if we see sufficient demand.

At a very high level, email is primarily used for discussions. With this view, successful innovation in the e-mail space requires innovation in the nature of discussions themselves. Tinkering around with better usability or feature improvements will not be sufficient to overcome the massive inertia of 'traditional e-mail'.

We are a startup that just launched (https://tmail21.com) that aims to rethink the discussion itself. In our view, one of the major problems of e-mail (and chat for that matter) is that the discussions are not goal-oriented. So, discussions/threads can meander around with no outcome or accountability.

So, we enhance the notion of discussions to be goal-oriented.

Now, once one has the notion of goal-oriented discussions, a natural next step is to evolve a goal-oriented discussion into a Lean Process (which is basically a goal-oriented discussion with more structure) . Examples of a Lean Process might be a Blog Article process, a Product Deployment Process, a Feature Design Process, an Issue Escalation Process etc.

We've done all this in an email-LIKE interface. I guess we'll leave it to others to decide whether this constitutes innovation in the e-mail space :)

So, what are Lean Processes? Lean Processes are the antithesis of rigid BPM tools.

Here are the key concepts behind lean processes:

1) They are oriented towards knowledge workers (rather than I.T. employees or straight task workers).

2) They allow knowledge workers to start with simple discussions then progress towards goal-oriented discussions and finally lean processes. So, rather than starting with a fully formed abstract process, the idea is to start with examples, observe patterns and then rapidly iterate.

A related idea is to allow users to rapidly achieve Process-Problem fit. (This is analogous to the Product-Market fit concept from the Lean Startup methodology)

3) Zero-Code or Code-Later: The philosophy of Lean Processes is that knowledge workers need to be able to rapidly iterate on processes. Accordingly, anything that slows this iterative process down (such as requiring support from I.T.) is discouraged. To the extent that integration is required a code-later philosophy is implemented which allows a hardened process to be integrated with no interruption in the knowledge-worker flow.

4) Guidance and Support rather than Control: Traditional BPM is more geared towards a high-level of prescriptiveness and control. The Lean Process philosophy is that these types of processes are better handled by apps. Lean Processes are geared towards guidance and decision support. A related concept is that there is expected to be significant variation in processes and which requires a lean process system to be adaptive.

5) Communication and Collaboration are central to Lean Processes: Communication and collaboration need to be tightly integrated into the lean process.

6) Lean Processes span intra-business, B2B and B2C processes.

Obviously Heinlein had not encountered Facebook where no random thought is too minor to be broadcast to all your 'friends' :)