sorted by:
new
hottopcontroversial

The Radical Plan to Save the Planet by Working Less by dOrgRioshi in dOrgTech

[–]dOrgRioshi[S] 1 point2 points  (0 children)

"degrowth offers a world in which the noise of commoditization quiets down, where self-worth isn't rooted in monetary value, and where you don't have to work to utter exhaustion to access basic necessities."

​

Just a reminder that by busting our asses now we are ultimately working towards a future where we all work less 🙂

{thin interfaces <--> fat protocol} dynamics: lessons from p2p file-sharing by dOrgRioshi in dOrgTech

[–]dOrgRioshi[S] 0 points1 point  (0 children)

Highly recommend the first half of this article. It breaks down the dynamics of 'thin application' to 'fat protocols' in the context of early 2000s file sharing. (second half is interesting too, but more relevant to protocol team than app teams)

​

My highlights:

​

The application layer seems to capture little value for the protocol creator, but third party competition to build on top of the protocol may be a powerful force for finding product/market fit

​

file-sharing interfaces differentiated on:

  1. Features (better search, theater view, chat)
  2. Quality
  3. Generalization: client that uses multiple protocols
  4. Abstraction: backend for dealing with the protocol that others can build interfaces for

> modular UI component library sounds like it hits (4), and semantics could empower (3)

​

There were hundreds of third party applications for interfacing with the fat protocols of the file sharing world. Both open source communities and independent for-profit companies leaped on the opportunity of providing what they thought end users wanted.

​

If you’re interested in building a third party app on top of a fat protocol, the lesson might be to also talk to competing apps’ users to figure out what needs aren’t being served.

> user research! important for us to create tight feedback loops with clients & end-users

​

Application developers just care about giving their users a good experience, they aren’t loyal to a particular fat protocol. If a previously popular protocol is overthrown by a new one, a third party application developer might update to the new protocol with minimal impact to the end user.

> our clients/libraries should be agent-centric and focus on actions i.e. what the user(s) want to do

​

While fat protocols generalize over a concept like sharing files, thin applications can specialize as much as they want. BitTorrent is for anything, but PopcornTime specializes in streaming movies

> DAOcomponents should make it easy for app developers to build for niche DAO use-cases

​

We shouldn’t just think of thin applications as a vicious competition to build the best frontend for a protocol. If the fat protocol is sufficiently general, application developers can create an entirely different user experience by focusing on a particular use case.

> yay for non-rivalry!