Live data from Hacker News

Bring Your Own Client

geoffreylitt.com

31–40 of 262 posts

Re: Bring Your Own Client

#31

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…

I think your point is spot on and probably one of the bigger reasons why we won't see any change happening in the Google Docs department.

Re: Bring Your Own Client

#32
post #6

Git 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…

I think that's close to what overleaf.com is doing for LaTeX.

Re: Bring Your Own Client

#33

I 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…

Decentralized Identifiers are aimed to solve this, basically having interoperable identifiers you can use across different applications but still referring to the same user.

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

#34
I’m reading Thinking Forth at the moment and there’s a part in the description of Forth about how it decouples words from their parameters and return types by only allowing stack manipulation. This means that all words share a common interface and so they’re infinitely composable. The reason I started reading this book is due to learning how WebAssembly works which turns out to be quite similar to Forth. It got me thinking if there might be a way to make all code modules interoperable. Being able to compose an application or client out of many independent parts would be a dream come true.

Re: Bring Your Own Client

#35
What about options of importing and exporting files? For example Google Docs lets download your file in another format making it easy to open in another client e.g. MS Word. Wouldn't that be somewhat of a BYOC approach.

Re: Bring Your Own Client

#36

The 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…

We need NPT for software

https://en.m.wikipedia.org/wiki/National_pipe_thread

Re: Bring Your Own Client

#37
post #5

This 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/

There can be considerable use-value to ecosystems which don't move as a whole, or do so with deliberation and in a component-wise manner.

As with, say, LaTeX, or Unix/Linux.

Re: Bring Your Own Client

#38
It seems like local-first software is a good foundation for promoting Bring Your Own Client more broadly.

It 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:

https://news.ycombinator.com/item?id=26356391

Re: Bring Your Own Client

#39
Another one is storing data, Apple for instance can easily lock in users with iCloud because it is so much more complicated keeping all devices and apps in sync without, with iCloud you have one login for passwords, browser, files, etc.

In 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

#40
post #5

This 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/

> Reddit replaced Usenet

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.

Post reply on HN