Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bring Your Own Client

geoffreylitt.com

Post reply on HN
Print view View original

91–100 of 262 posts

Re: Bring Your Own Client

#91

Post by zomglings »

Cthulhu_ wrote: post #89
zomglings wrote: post #87

The problem (currently) is that most people simply don't care about being forced to use a particular client - as long as that client looks nice. I say this with a lot of love for the idea. My company sells a collaborative knowledge base that supports Bringing Your Own Client. Out of the hundreds of users I have spoken to, only ONE has ever asked me if they could use their favorite markdown editor to access their know…

I think it makes sense to at least have the mindset from a developer's point of view. It helps prevent lock-in between the client and whatever APIs or storage your product uses. I've tried to build apps with a strict client / server separation for a decade now, it made sense at the time because of mobile apps, and it makes sense now due to application half-life (front-ends don't last as long as their back-ends). In m…

Agreed - with the understanding that maintaining distinct clients is a LOT of work.

Re: Bring Your Own Client

#92

Post by grishka »

lultimouomo wrote: post #53
nickez wrote: post #50

Earlier quoted context omitted.

Can you imagine a world where you could only use a specific phone model with a specific operator? or where you could only send text messages to people that is on the same network? If we can regulate phones we should be able to regulate social networks.

When the iPhone originally came out in the US it was locked together with a 2 year contract with AT&T.

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

Re: Bring Your Own Client

#93

Post by xd1936 »

falcolas wrote: post #67
rakoo wrote: post #52

I don't see Google Drive ever providing an API for bringing your own client; it will probably have to be from the other side. We already have OT and CRDTs for concurrently defining changes from each user and a way to merge them. There is also the Braid spec ( https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b... ) attempting to standardize state synchronization on top of which one can bring any client

> I don't see Google Drive ever providing an API for bringing your own client In a way, they already have, since you can mount your Google drive on your local file system, and interact with the files from there. The problem lays with the proprietary Google Doc format.

https://developers.google.com/docs/api

Most things you would want to do to a Google Doc are available via oAuth API, right?

Re: Bring Your Own Client

#95

Post by gklitt »

rakoo wrote: post #52

I don't see Google Drive ever providing an API for bringing your own client; it will probably have to be from the other side. We already have OT and CRDTs for concurrently defining changes from each user and a way to merge them. There is also the Braid spec ( https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b... ) attempting to standardize state synchronization on top of which one can bring any client

Yes! I think Braid is a good effort in this area, will add to the prior art section.

Re: Bring Your Own Client

#96

Post by falcolas »

xd1936 wrote: post #93
falcolas wrote: post #67

Earlier quoted context omitted.

> I don't see Google Drive ever providing an API for bringing your own client In a way, they already have, since you can mount your Google drive on your local file system, and interact with the files from there. The problem lays with the proprietary Google Doc format.

https://developers.google.com/docs/api Most things you would want to do to a Google Doc are available via oAuth API, right?

Not... really? I can't open it with a local application.

At least, not until someone (not me, no time) creates a local application which interacts with Google Docs via this API.'

In the mean time, I'll continue to use .docx, since Google docs can export and import form this format.

Re: Bring Your Own Client

#97

Post by api »

kjrose wrote: post #83
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…

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.

Re: Bring Your Own Client

#98

Post by gklitt »

folex wrote: post #90

Background gradient makes me dizzy after reading a single paragraph

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

Re: Bring Your Own Client

#99

Post by julienreszka »

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…

We need not only separation of storage and UI but also labeling providers between the ui and the data so you can find your data easily.

Re: Bring Your Own Client

#100

Post by grishka »

rapnie wrote: post #28
blfr wrote: 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/

> This idea suffers from the same problem federation does. Yes, this is a problem you also see with the Fediverse (based on W3C ActivityPub). You get innovators and laggers, and the latter when they are popular can hold the former back (you see this with Mastodon, which as early adopter created their own client API's, but are now lagging to implement the Client-to-Server part of the AP specification). At the same tim…

The C2S part of ActivityPub isn't for everyone, and it's okay. It basically moves too much logic to the client. It prevents any semblance of a good UX because you have everything — posts you would display in the feed, interactions with your content, etc — in the same inbox. You have to connect to many different domains to render something to the user, and you also have to have a sophisticated caching system on the client. Also good luck loading those full-size images over an EDGE connection.

There are 2 kinds of ActivityPub servers.

- The "dumb" one, that does minimal processing and simply stores JSON objects. Someone POSTs an activity to its inbox, the server does minimal required verification, stores it, and the client then queries it with GET. And does the reverse for the outbox. That's it. That's where c2s would work fine.

- The "smart" one, that treats s2s ActivityPub like an API, comes with a built-in web interface, and stores everything in a way which makes sense for its particular presentation. That's the kind I'm making (Smithereen, it's on the list you linked, btw), and that's what Mastodon is. Implementing c2s in this kind of server is a major pain in the ass, and I won't. You'd have to throw away all your careful optimizations, synthesize ActivityPub objects out of things that never were ActivityPub objects in the first place, do horribly inefficient things to merge notifications and feed and other conceptually unrelated stuff from several different database tables just for the client to split them back apart... Doesn't make much sense. A domain-specific API is the only way to make a client for this kind of server.

Post reply on HN