Bring Your Own Client • Hacker News Board

Re: Bring Your Own Client

#131

Post by TheRealDunkirk » Fri, Mar 05, 2021, 3:39 PM UTC

stupidcar wrote: post #11

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…

> without government intervention

Well that's the real trick, isn't it?

Our government is "captured" by campaign financing. Now we have 2 problems: ineffective governmental oversight, AND Citizens United. We have to solve the latter before we can ever solve the former.

Re: Bring Your Own Client

#132

Post by ori_b » Fri, Mar 05, 2021, 3:40 PM UTC

bombcar wrote: post #2

This strikes at something that people often WANT when they say "text files are better than the registry/binary formats" - they want to easily bring their own tooling to bear. Standard APIs let you do this - even if you have a "binary format" like MySQL or PostgreSQL (on disk) - nobody really complains about that because they have a defined API you can interact with.

Standard APIs still can require a fair amount of code to write. A plain text format with a well defined grammar allows me to pull out any old text editor, and get to a working change with trial and error.

Protocols and binary formats have their place too -- but there's simply nothing as universal as text.

Re: Bring Your Own Client

#133

Post by thomastjeffery » Fri, Mar 05, 2021, 3:42 PM UTC

lewisjoe wrote: post #29

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…

Rich text is expressed with markup. The rest can be done with protocol.

Just like clients would have to implement markup parsing and rich text rendering, they would need to implement protocol endpoints like notifications,etc.

Re: Bring Your Own Client

#134

Post by grishka » Fri, Mar 05, 2021, 3:44 PM UTC

nemothekid wrote: post #123

grishka wrote: post #92

Earlier quoted context omitted.

And it took how long for people to figure out how to unlock it?

No amount of unlocking would have enabled you to use your iPhone in the second largest operator in the US; Verizon

Ah. Right. I always forget that the US is about the only country in the world where there still are widely used CDMA networks.

Re: Bring Your Own Client

#135

Post by ivan888 » Fri, Mar 05, 2021, 3:45 PM UTC

api wrote: post #97

kjrose wrote: post #83

Earlier quoted context omitted.

Well it can happen if a significant enough open source project establishes a protocol early enough and doesn't get co-opted. That or a consortium of companies agree on some sort of standard. (See the work on pc buses in the early pc days) But you are right. When companies run under trying to get as many users locked in as possible during a paid for investors period. This model is precisely the opposite outcome expect…

For something to get traction, it has to have excellent UI and UX. So far open source hasn't been very successful at providing that since there is no economic model to finance the immense amount of work required for good UX.

I posited a similar point to a former colleague (mine was more about eventual market dominance due to excellent UI+UX), and he came back with Craigslist as a perfect example of a product that gained a massive user base well into an era where its UI felt very outdated. A few years after this exchange, I feel more like I was right about my point: FB Marketplace has almost completely taken over as far as a classified product marketplace, but the point still stands that Craigslist was able to do a ton with very lackluster UI+UX

Re: Bring Your Own Client

#136

Post by stickfigure » Fri, Mar 05, 2021, 3:46 PM UTC

stupidcar wrote: post #108

pjc50 wrote: post #79

Earlier quoted context omitted.

Think it through: > 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 with a separate storage provider. Now, is the law going to mandate the exact API as well? The likely implementation of this is that, just as every app developer co…

Your objections seem to be predicated on the assumption that the attempt to separate storage providers from application providers wouldn't be properly enforced. Yes, obviously if Alphabet can just set up Google Cloud Storage and Google Cloud Apps and continue with business as usual, then this won't work. But what I'm suggesting would be a functioning regulatory regime: An independent authority who classifies cloud pr…

Any such regulatory regime would serve primarily to entrench incumbents by creating vast compliance requirements on newcomers. How's your healthcare startup doing?

You imagine a benevolent dictator making optimum choices. I think the F35 design/procurement process is a better metaphor.

Re: Bring Your Own Client

#137

Post by derefr » Fri, Mar 05, 2021, 3:54 PM UTC

Re: Notion, Trello, etc. — wouldn’t enabling interoperability on top of a presumably-free “open core”, completely commoditize these services? (As, for anything they offered on top of their open core, you could instead substitute a third-party service that does the same thing by operating against the service’s API.)

Which is to say — in a world where interoperability is a social norm or legal requirement, how would these services exist? (I would suspect they wouldn’t.) And, without them, would there be any money in advancing the state of the art in these verticals?

It’d be a lot like if there were a legal requirement for every drug to have a generic available from the start. Would there still be an incentive for drug research?

Re: Bring Your Own Client

#138

Post by pbreit » Fri, Mar 05, 2021, 3:54 PM UTC

Unirest is the BYOC that I was hoping would get traction: https://github.com/kong?q=unirest

I don't understand why each API needs it's own SDK. Or even why developers use SDKs instead of just calling the RESTful endpoints directly.

Re: Bring Your Own Client

#139

Post by TeMPOraL » Fri, Mar 05, 2021, 3:55 PM UTC

ivan888 wrote: post #130

kjrose wrote: post #83

Earlier quoted context omitted.

Well it can happen if a significant enough open source project establishes a protocol early enough and doesn't get co-opted. That or a consortium of companies agree on some sort of standard. (See the work on pc buses in the early pc days) But you are right. When companies run under trying to get as many users locked in as possible during a paid for investors period. This model is precisely the opposite outcome expect…

One of the better examples still seeing widespread mainstream use is email, and this even applies to multiple stages throughout the email ecosystem: sending mail, receiving mail, managing mailboxes. Imagine if email wasn't cross provider compatible

The surviving open protocols are like libraries: they were created before the space got commercialized. They got grandfathered in. If libraries didn't exist for centuries already, there is no way they could have been created under current intellectual property laws and IP economy. Similarly, new open protocols don't generally gain widespread adoption - and in the rare case they do, that's only because some companies are using them to gain adoption; once those companies gain the market share they want, they switch to proprietary protocols and the open one dies. See e.g. Google and XMPP or RSS.

Re: Bring Your Own Client

#140

Post by wongarsu » Fri, Mar 05, 2021, 3:56 PM UTC

pjc50 wrote: post #79

stupidcar wrote: post #42

Earlier quoted context omitted.

Can I ask why? As I see it, cloud providers are currently entrenched as Lords of Everything because they can both provide the infrastructure and the products that run on top of it. Making them act more like utility providers would reduce their power, I think.

Think it through: > 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 with a separate storage provider. Now, is the law going to mandate the exact API as well? The likely implementation of this is that, just as every app developer co…

With storage we already have "S3-compatible" as a widely implemented and supported standard. Just allow the user to set an arbitrary API endpoint for your regular S3 library and you support a breath of providers