Hacker News Reader

Comment by Ajedi32 | Hacker News Reader

Wow! I actually love the idea of being able to interact with websites via a standard API rather being forced to use web-based UI they provide. It opens up a whole lot of possibles for things like alternate clients, standard UIs for interacting across multiple sites, etc. Also eliminates the possibility of sites engaging in annoying or abusive behavior by putting users in full control of the client rather than the site operator. Obviously it can't work for every site, but it's quite the interesting concept.

View on HN

> I actually love the idea of being able to interact with websites via a standard API rather being forced to use web-based UI they provide.

For a while, people were pitching this as Web 2.0. It's also what RSS and podcasts still are.

Unfortunately, most of the websites we visit are revenue-generating and want to control their presentation.

> most of the websites we visit are revenue-generating and want to control their presentation

This project seems designed to work even without the cooperation of the sites you're interacting with; all the site-specific modules are maintained by the community. Adversarial interoperability at its finest.

In extreme cases, one could imagine a module running a full headless browser on the back-end, pretending to be a user scrolling around and clicking stuff, while presenting the actual user with a clean front-end.

Right. There are all kinds of great services that could be built on top of other peoples' web sites, but most sites want to own the relationship with their customer directly. And most of the great ideas for mashup services are predicated on the idea that the mashup will get most of the revenue, which is not going to fly with the underlying value providers. In an ad-supported web world, those who own the eyeballs call the shots.

It's a tricky problem. I just have to believe there's a way we can make the world work without ads at all. They're just gross. But I have no idea how that could happen.

I've had two ideas related to this in the past that I've always wanted to prototype:

- A social media website without a frontend. We just provide a fully exposed API and Oauth, and devs can create their own client to interact with the social network. This would give devs the freedom to create their own experiences without locking users into one specific way of using the social network.

- "Cloud" content hosting as a service. You'd be able to build your own frontend for interacting with a website / blog, and then include our JS code and your site's content will automatically be populated in. This would keep the frontend clean, simple, and cheap, while offloading posts, comments, and other advanced functionality to the service.

Of course both are purely experimental ideas, with no potential real world meaning :D

You just invented Web 2.0!

Not being a jerk but this concept was one of the major ideas behind Web 2.0 but fizzled out. Services would provide data endpoints that your user agent (browser or whatever) would tie together. Even your identity was just a bunch of meta tags in the headers of your web page pointing to things like FOAF or OPML files that linked to people you knew or sites you liked.

Your User Generated Content would just be your blog posts that could be easily followed by someone with an RSS reader. Things like photos or videos would work the same way as someone would just follow your Flickr feed (which you could point to with a metatag on your homepage.

The key takeaway was that everyone would host their own data, deciding what to publish or make public, and then smarter clients (other sites or apps) would collect this information and do whatever graph analysis you wanted.

But normal people do t want to run their own servers and tying disparate services together is non-trivial. So we got UGC but it was/is hosted on social media sites. They made it easier to put together an online presence than self-hosting everything.

For your first idea around social media, while not 100% exactly what you cited, the fediverse sort of already provides for that...Well, specifically the ActivityPub protocol (and couple of other protocols) enable such functionality...and frankly there are numerous (yes, not just 1 or 2, but numerous) server implementation which further enable numerous desktop and mobile clients to interact with content...all federated/sort of decentralized. If you've heard of mastodon, then they tend to capture most of the mindshare, but there are many other servers and clients...and there are reportedly millions of people on the fediverse around the world...so we're sort of already where you would like to be. ;-)

I'm sure there are many sites which help provide better context for the fediverse, but here, check this one out: https://fediverse.party/en/fediverse

Cheers!

> A social media website without a frontend. We just provide a fully exposed API and Oauth,

Take CouchDB and store all activities as ActivityStreams documents.

> "Cloud" content hosting as a service.

"Headless CMS" is the term you are looking for, and it is already a big industry https://jamstack.org/headless-cms/

For the social media part that existed; see https://socialize.dmonn.ch/

It has fallen out of fashion tho.

this sounds perfect for https://www.deso.org/ social network code

Isn’t this the company that did “log in with seed phrase”?

That’s the one but look deeper. Nader has a vision.

In a way you’re describing how browsers should work.

> Also eliminates the possibility of sites engaging in annoying or abusive behavior by putting users in full control of the client rather than the site operator. Obviously it can't work for every site, but it's quite the interesting concept.

That’s the job of the User Agent after all, acting on behalf of the user.

I actually love the idea of being able to interact with websites via a standard API rather being forced to use web-based UI they provide.

That's what HTTP is. You're free to write a client that isn't a browser that sends and receives the same API messages as any HTTP client app does. Most people use browsers, but there's also things like iOS and Android apps that consume the same APIs as browsers, or Postman that directly communicates with the APIs, etc.

The APIs that sit in top of HTTP are even sort of standardized in the sense that HTTP verbs mean the same everywhere (in theory, but some devs get it wrong.)

Thr only hard bit that no one has really solved in a nice way is how you discover the APIs in the first place. There's things like WSDL but it's horrible.

GraphQL schemas almost seem like the least worst current option and I'm not entirely happy to be saying that.

Isn't this just what Electron provides?

Reply on news.ycombinator.com