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
vrypan |--o--|
@vrypan.eth
My main counter-argument to narrow types, is that, more or less, we have agreed that the "standard feature set" space is and will be dominated by Warpcast at least for the near future. So, making this easy vs something totally out of the WC norm, limits experimentation in areas that are not in the MM radar.
0 reply
0 recast
3 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
