The main reason for using google docs is not it’s superlative editor... /sarcasm It’s the collaboration features. And no I don’t mean the multiple people typing the doc at the same time. It’s the ability to quickly share a document with a set of people that you want. Sure I use Vim every day, but without that git push and a trip to GitHub to invite collaborators I’m a man on a desert island waiting for that next week…
Bring Your Own Client
31–40 of 262 posts
Re: Bring Your Own Client
#32Git does not have colaboration tools. It's very much a "work in a silo for a period of time and then evtually figure out how to mash these things together" approach.
Has anyone tried to build real-time collaboration on git? What if every participant would run a system that saved on every keystroke, committed and synced with the remote? It would break due to conflicts as soon as two concurrent edits were too close to each other, but you could probably just accept either commit when they’re so granular and happening in real time. The conflict is going to be obvious and fairly easy…
Re: Bring Your Own Client
#33I work on a popular Google Docs alternative product in the market. I gave some thoughts around this idea of experimenting a standard for collaborative rich text, that any client can implement. The problem though is that people want easy collaboration, more than the freedom to bring their own clients. To simply put how can we deal with assigning people (for @mentions, comments, document ownership and content locking f…
Initial concept for DIDs were made for blockchains and other decentralized projects (I think, someone please correct me if I'm wrong) but useful for federation or for centralized projects that want to offer flexible data migration too.
- Specification: https://www.w3.org/TR/did-core/
- https://en.wikipedia.org/wiki/Decentralized_identifiers
- One organization working on DIDs: https://identity.foundation/
- Project leveraging DIDs: https://sovrin.org/
Re: Bring Your Own Client
#34Re: Bring Your Own Client
#35Re: Bring Your Own Client
#36The competitive advantages of owning both the application and the data are so high that don't see widespread BYOC ever happening without government intervention. I'd like to see an enforced separation in law between commercial application providers and storage providers. So, if someone writes an app like Google Docs, they can't just store the data opaquely on their own cloud servers. They legally have to integrate wi…
Re: Bring Your Own Client
#37This idea suffers from the same problem federation does. It's harder to move a whole ecosystem. Makes it harder to innovate. Leads to centralized platforms outperforming these BYOC/federated/open options. Basically how Reddit replaced Usenet with upvotes and basic spam filtering. There's more on this from 'moxie https://www.youtube.com/watch?v=Nj3YFprqAr8 https://signal.org/blog/the-ecosystem-is-moving/
As with, say, LaTeX, or Unix/Linux.
Re: Bring Your Own Client
#38It also goes hand in hand with end-to-end encryption. This sounds a lot like the Case I made for building Client-First web apps, I just posted it on HN:
Re: Bring Your Own Client
#39In theory a shared folder with clients that handle multiple devices/operating systems in their dot-files well would be able to replace that, but with most phones in a closed ecosystem, I don't see that happening.
Re: Bring Your Own Client
#40This idea suffers from the same problem federation does. It's harder to move a whole ecosystem. Makes it harder to innovate. Leads to centralized platforms outperforming these BYOC/federated/open options. Basically how Reddit replaced Usenet with upvotes and basic spam filtering. There's more on this from 'moxie https://www.youtube.com/watch?v=Nj3YFprqAr8 https://signal.org/blog/the-ecosystem-is-moving/
Many things replaced Usenet. Usenet is more of a protocol (that uses NNTP) than a social media platform. If you're any way a systems thinker, you would know that protocols are more resilient than services.