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

181–190 of 262 posts

Re: Bring Your Own Client

#181

Post by MichaelApproved »

polote wrote: post #175
MichaelApproved wrote: post #173

Earlier quoted context omitted.

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

First, that’s not the full spec for Google docs. It’s missing many aspects of the environment.

Second, is that meant for building a full blown client or is it meant for 3rd party integrations, like plugins?

Re: Bring Your Own Client

#182

Post by tshaddox »

dnissley wrote: post #180

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…

Tweetbot on iOS supports hiding images in tweets (but not hiding avatars). It costs a bit of money, but I have bought every version so far.

Re: Bring Your Own Client

#183

Post by karatinversion »

bombcar wrote: post #158
SahAssar wrote: post #115

Earlier quoted context omitted.

Calendaring is surprisingly complex. Especially when it comes to stuff like rules for repeating events and timezones. I had to do work on this at a previous job and it was pretty hard even with all the libraries and tools out there.

It's insanely complex - one of those problems that is easy to state and nearly impossible to solve (which means there's opportunity here).

Or in a lot of places, that’s Microsoft outlook’s moat

Re: Bring Your Own Client

#184

Post by 3np »

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…

OTOH, give it time. Open alternatives exist for every private walled garden. I believe the decentralization/federalization and FLOSS movements have a real chance, even if they move at 0.05 velocity. Private platforms are subject to closure, but the light of an open source project will shine as long as there's someone spending time on it.

In due time we'll have networks of small providers catering for BYOC hosting. Cryptocurrencies can play a part in efficient and fair compensation.

But then again, maybe by the time we catch up to current date, everything happens in walled VR moats.

Maybe I'll be the oddball in the metaphorical cabin in the woods, but given the progress we're making so far I'll refuse to enter a closed VR/AR ecosystem.

Re: Bring Your Own Client

#185

Post by nippoo »

For the "todo list" item: check out Todo.txt and any number of the clients that use the same, human-readable/editable text-based format. I really enjoy being able to choose the client I want on my Mac, iPad and Android phone while keeping the same todo list file...

Re: Bring Your Own Client

#186

Post by Bishop_ »

moistbar wrote: post #155
rozab wrote: post #144

Earlier quoted context omitted.

I think it's not completely inconceivable that this could be regulated some day with music streaming. There are zero technical hurdles (unlike with complex apps like Google docs), and because there is such potential for decoupling the client the consumer benefits would likely be much greater. I've been meaning to switch from Apple Music to Spotify for a while now (I'm on Android). I just had a look around the Spotify…

You should check out Spot[0]. It's a Spotify client written in Rust using GTK. It's quite barebones at the moment and only works with premium accounts, but the interface is much cleaner than the official Spotify client. [0] https://github.com/xou816/spot

If a terminal is more your style you can even use Spotify-tui[0].

Requires some setup and having an additional client installed for the actual audio playback but it's still interesting using Spotify from a terminal.

[0] https://github.com/Rigellute/spotify-tui

Re: Bring Your Own Client

#187

Post by munificent »

eric4smith wrote: post #20

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…

> It’s the ability to quickly share a document with a set of people that you want.

In particular, it lets you do that while maintaining a single source of truth.

It's equally easy to just email people a document. But then if you change the doc, they still have the old version. Maybe they forwarded it on to some other people you don't know about it after making some changes. The next thing you know, there are twenty versions of this file floating around all slightly different and everyone thinks they are on the same page.

Re: Bring Your Own Client

#188

Post by TimTheTinker »

3np wrote: post #184
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…

OTOH, give it time. Open alternatives exist for every private walled garden. I believe the decentralization/federalization and FLOSS movements have a real chance, even if they move at 0.05 velocity. Private platforms are subject to closure, but the light of an open source project will shine as long as there's someone spending time on it. In due time we'll have networks of small providers catering for BYOC hosting. Cr…

Maybe the best solution would be legislated government donations to open source projects, with a mandatory legislative bill each year on who they go to.

Re: Bring Your Own Client

#189

Post by gklitt »

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…

(post author here)

While I agree that commercial incentives are critical to consider, two caveats I'd add:

1) I think the nature and depth of the incentives problem varies a lot by industry. Social media is a really complex case, for example. But I'm most interested in collaborative productivity tools, where I think many companies are okay being incentivized to build the best product rather than build data moats.

2) Cutthroat commercial incentives aren't the only thing that got us here. There are also tech barriers.

If I was starting a Google Docs competitor today, even if I wanted to make it open, I think it would be hard to pull off. What kind of API would I expose to enable realtime editing with good offline mode and conflict resolution? How would I deal with clients that have slightly different rich text representations than my own?

In an alternate universe where we already had a user-owned "web filesystem" with good answers to these questions, I could just hook up my client to that existing system and not even worry about persistence at all. It needs to be _easier_ for devs to build the right thing for users, not harder. And it needs to be a _better_ experience for end users, not a sacrifice. The convenient thing will win.

Re: Bring Your Own Client

#190

Post by gmfawcett »

kjrose wrote: post #142
ivan888 wrote: post #130

Earlier quoted context omitted.

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

Absolutely, however a major problem occurs, and email is a great example of this. When there is a fundamental need to change the protocol for reasons of privacy, security, authentication, etc. It becomes almost impossible to do when it is as wide spread as email, or it takes a very very long time to spread enough. When one person controls the whole system, it's easy to pivot rapidly. I guess that's another argument a…

I think that's a great argument for keeping widely used protocols. I don't want any one person, or one entity, to rapidly pivot my critical infrastructure (whether it is "broken" or not). The slowness of change is a feature.
Post reply on HN