Bring Your Own Client • Hacker News Board

Re: Bring Your Own Client

#171

Post by dec0dedab0de » Fri, Mar 05, 2021, 5:04 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…

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 with a separate storage provider. And that storage provider has an obligation to make my data accessible and manageable by me.

I think that is a bit much, I would much rather make reverse engineering/screen scraping/whatever for interoperability be 100% legal with zero grey area. Including a bit that says TOS/Eula/NDA/NonCompete/any contract can not give away this right.

Edit: basically let asshole companies use technical means to try to stop us, but give them no legal recourse if we manage to get the cheese out of their trap.

Re: Bring Your Own Client

#172

Post by scottlamb » Fri, Mar 05, 2021, 5:07 PM UTC

pbreit wrote: post #138

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.

I think the problem described in this article is more fundamental: these services don't have documented, stable APIs for clients to build on. Not HTTP APIs. Not libraries either. In some cases they go out of their way to prevent third parties from using whatever internal API their own apps use. [edit to add: to combat abuse/spam, or because they have ads, or as deliberate lock-in.]

But to answer your question: when an API exists, why have an SDK? One reason is to provide strong typing (and everything that goes with it, like IDE auto completion). A very thin layer over the HTTP requests is enough to provide this. Eg, in one of my projects [1] I wrapped a HTTP API with Go calls like this:

    Method(ctx context.Context, req *MethodRequest) (*MethodResponse, error)

where each method call corresponds to exactly one HTTP request. It handles deadlines, cancellation, HTTP error checking, and using Go's built-in json marshalling/unmarshalling on structs. That's about all I want in an SDK. The unirest project you linked doesn't seem to offer strong typing so I wouldn't use it (even if it weren't dead).

[1] https://github.com/scottlamb/luxor

Re: Bring Your Own Client

#173

Post by MichaelApproved » Fri, Mar 05, 2021, 5:07 PM UTC

polote wrote: post #161

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…

> The competitive advantages of owning both the application and the data are so high Honestly this is wrong. Google drive has API for everything, Notion is working on an API, Confluence has API for everything, Trello ... Any serious text editor (and all the ones wrongly cited in the article) software has API for everything. Want to export your Confluence data to Notion ? you can. In the documentation tools space owni…

Those APIs are not meant for building a full blown dedicated clients, they’re for application integrations.

Re: Bring Your Own Client

#174

Post by hirundo » Fri, Mar 05, 2021, 5:21 PM UTC

This applies well to the remote work environment. My employer makes no requirement about which editor or terminal or operating system or anything else we use to access their resources. The deliverables are (mostly code) files, and they just don't care what we use to manipulate those. They don't provide any hardware either.

What reads to some as worker exploitation is actually empowerment in practice.

Re: Bring Your Own Client

#175

Post by polote » Fri, Mar 05, 2021, 5:21 PM UTC

MichaelApproved wrote: post #173

polote wrote: post #161

Earlier quoted context omitted.

> The competitive advantages of owning both the application and the data are so high Honestly this is wrong. Google drive has API for everything, Notion is working on an API, Confluence has API for everything, Trello ... Any serious text editor (and all the ones wrongly cited in the article) software has API for everything. Want to export your Confluence data to Notion ? you can. In the documentation tools space owni…

Those APIs are not meant for building a full blown dedicated clients, they’re for application integrations.

Check that https://developers.google.com/docs/api/reference/rest/v1/doc...

You have the full specification of Google docs documents and API to edit any kind of blocks inside

Re: Bring Your Own Client

#176

Post by zolland » Fri, Mar 05, 2021, 5:22 PM UTC

polote wrote: post #161

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…

> The competitive advantages of owning both the application and the data are so high Honestly this is wrong. Google drive has API for everything, Notion is working on an API, Confluence has API for everything, Trello ... Any serious text editor (and all the ones wrongly cited in the article) software has API for everything. Want to export your Confluence data to Notion ? you can. In the documentation tools space owni…

You touch on an important point here. Even if you were able to gain full access to the data behind say Confluence, the schema is probably very specialized to their client, contains lots of tech debt, and design is probably very opinionated. You would most likely find it easier to just write your own schema rather than integrate with theirs.

Re: Bring Your Own Client

#177

Post by marmada » Fri, Mar 05, 2021, 5:25 PM UTC

The problem with BYOC client for Google docs / Figma is that the underlying data isn't simple plaintext, it's too complex, and the protocol requires things like operational transforms, so BYOC wouldn't make sense.

Re: Bring Your Own Client

#178

Post by gklitt » Fri, Mar 05, 2021, 5:26 PM UTC

neurotrace wrote: post #146

gklitt wrote: post #98

Earlier quoted context omitted.

(author here) sorry to hear that! Out of curiosity, what screen size are you reading on? Anyone else have similar problems? Sounds like I should add a button to disable the gradient.

It's a cool idea but I wrote a userstyle to override it. Reading on a plain color is easier for me

Thanks for the feedback everyone! Never realized it was causing problems. Will change or at least add an option.

Re: Bring Your Own Client

#179

Post by simonebrunozzi » Fri, Mar 05, 2021, 5:28 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…

> 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.

This.

Re: Bring Your Own Client

#180

Post by dnissley » Fri, Mar 05, 2021, 5:32 PM UTC

I've got lots of small tweaks I'd love to incorporate into a Twitter client. Unfortunately, I think many of them would violate the developer TOS.

For example: hiding avatars completely or generating replacement avatars using the username to remove any chance of internal bias associated with an account's avatar. Another one: hiding images by default and forcing you to click to expand/open to see them (no previews). A lot of these ideas are intending to modify Twitter's default salience landscape.

However disappointing it might be though that I can't do this, I get it. These kinds of modifications could totally change the ways in which a user experiences Twitter, and how Twitter would be able to monetize those users. Simply forcing Twitter (via legislation) to allow BYOC doesn't seem like a good idea because of this. It doesn't seem right to force them to run a service with a reduced potential for monetization -- e.g. many clients could just not show any ads, which would totally remove Twitter's ability to monetize at all.

An idea might be to charge users money in order to allow BYOC, so Twitter could focus on building out the core offering, which is just basically the public messaging substrate of the internet. But I'm not at all sure how well that would work out in practice.