Content
@
0 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
Broad vs Narrow data types (for example, cast location vs external data FIPs) I'm in favor of broad types. I like how RSS enclosures allowed podcasting to emerge (and practically this is the only broadly used RSS application today). Broad types allow clients to implement new features without protocol updates -more permissionless from a dev pov. On the other hand, narrow types create a well-defined, well-scoped environment, easier to navigate for devs who want to implement a standard feature set. What's your take?
2 replies
1 recast
6 reactions
KMacđ â© ă
@kmacb.eth
The app driven protocol dev philosophy & practice of Merklem seems to kneecap Broad data types esp if those donât fit into their word view of a social network that is x like err Reddit like err Patreon like err⊠Imagine if smtp only let you send personal emails instead of work related or controlled the available subject lines or dictated what could go in attachments. It may have been a slower adoption & smaller surface area. Some storage the community can play with to find what sticks & what grows to be a âstandardâ vs told this is the standard would be rather empowering for devs.
1 reply
0 recast
0 reaction
vrypan |--o--|
@vrypan.eth
KMac woke up today and chose war. đ€Ł Each approach has its pros and cons. It's good to collect them and share them with each other. @dwr.eth said the he has changed his mind about (the near term feasibility of) alternative clients. Downstream from this, maybe other decisions/mental models should be reevaluated too. If you expect to have 10 competing twitter clients, narrow types give a clear path to feature parity. If you hope to get a twitter-like client, a social p2p media sharing app, a social event scheduler and a small businesses directory, event parity is irrelevant but freedom to experiment is required.
2 replies
0 recast
0 reaction
