it's hard to explain how the fediverse works correctly because it fundamentally doesn't make sense.
-
it's hard to explain how the fediverse works correctly because it fundamentally doesn't make sense. incorrect assumptions everywhere. design dna imported uncritically from centralized siloed platforms will inevitably lead to a bad ux when applied to decentralized systems. somehow, things were less contradictory back in the gnu social and ostatus days -- a feed is a feed. current fedi seems to be very keen on obscuring the base reality on which it operates, just like the silos they emulate.
-
it's hard to explain how the fediverse works correctly because it fundamentally doesn't make sense. incorrect assumptions everywhere. design dna imported uncritically from centralized siloed platforms will inevitably lead to a bad ux when applied to decentralized systems. somehow, things were less contradictory back in the gnu social and ostatus days -- a feed is a feed. current fedi seems to be very keen on obscuring the base reality on which it operates, just like the silos they emulate.
the rise of facebook/twitter/instagram/etc make a lot more sense when you recognize that the core innovation they brought to the table was actually enclosure of the web. yes, it's "simpler" when you don't have to deal with any actual decentralization. you no longer have to deal with incomplete untrusted information as you do in open-world models; everything is known to you in the closed-world model.
we have *got* to do better than just trying to build "x but federated". lean into the web.
-
the rise of facebook/twitter/instagram/etc make a lot more sense when you recognize that the core innovation they brought to the table was actually enclosure of the web. yes, it's "simpler" when you don't have to deal with any actual decentralization. you no longer have to deal with incomplete untrusted information as you do in open-world models; everything is known to you in the closed-world model.
we have *got* to do better than just trying to build "x but federated". lean into the web.
say what you will about indieweb specs but at least you get to pick and choose which ones make sense to implement for yourself. and the fundamental model of the indieweb is inarguably still "web". no obscuring anything.
-
the rise of facebook/twitter/instagram/etc make a lot more sense when you recognize that the core innovation they brought to the table was actually enclosure of the web. yes, it's "simpler" when you don't have to deal with any actual decentralization. you no longer have to deal with incomplete untrusted information as you do in open-world models; everything is known to you in the closed-world model.
we have *got* to do better than just trying to build "x but federated". lean into the web.
@trwnh hopefully related, I've been thinking about a sort of browser extension in the vein of fediact/graze that you connect an account to and it'll expose certain account details etc via an API. if elements have special attributes on the page then you can click on them and the extension will like/boost/reply/etc for you. if there isn't anything that it can hook into but it still detects activitypub or whatever then it'll pop up a bar with buttons that let you do that.
sort of a pipe dream but it's something that would certainly help things along in making it more of a social Web like you're talking about if I'm not wrong
-
@trwnh hopefully related, I've been thinking about a sort of browser extension in the vein of fediact/graze that you connect an account to and it'll expose certain account details etc via an API. if elements have special attributes on the page then you can click on them and the extension will like/boost/reply/etc for you. if there isn't anything that it can hook into but it still detects activitypub or whatever then it'll pop up a bar with buttons that let you do that.
sort of a pipe dream but it's something that would certainly help things along in making it more of a social Web like you're talking about if I'm not wrong
@eblu yeah, ideally the “social” part would be built into your actual web browser. web browser extensions is a valid way of doing that. you just need to agree on or standardize two things:
1) an identity system (right now, the closest to that for “the web” is dns names or http(s) uris — “i am (http(s)://)trwnh.com” — it’s possible did stuff can work here too, as bluesky demonstrates)
2) a way to publish resources on that identity (right now, the closest to that is webdav or solid) -
@eblu yeah, ideally the “social” part would be built into your actual web browser. web browser extensions is a valid way of doing that. you just need to agree on or standardize two things:
1) an identity system (right now, the closest to that for “the web” is dns names or http(s) uris — “i am (http(s)://)trwnh.com” — it’s possible did stuff can work here too, as bluesky demonstrates)
2) a way to publish resources on that identity (right now, the closest to that is webdav or solid)@eblu basically you should be able to establish an identity session with any website or web server (to see private resources) and you should be able to hook back into whatever is powering your website via a standard api (to publish your response)
solid uses webid and oidc for the identity bits, and HTTP PUT with the Authorization header for the publishing
indieweb tends to use micropub endpoints which are more limited to “post” type resources rather than allowing arbitrary documents, + oauth
-
@eblu basically you should be able to establish an identity session with any website or web server (to see private resources) and you should be able to hook back into whatever is powering your website via a standard api (to publish your response)
solid uses webid and oidc for the identity bits, and HTTP PUT with the Authorization header for the publishing
indieweb tends to use micropub endpoints which are more limited to “post” type resources rather than allowing arbitrary documents, + oauth
@eblu i think the hard part is getting everyone on roughly the same page with identity and how to make use of it. you could generate a keypair and have your browser sign http messages, or you could wait until fedcm is ready and offload that to an explicit “identity provider” service.
for the publishing apis, it’s mostly a matter of which ones you support. a micropub endpoint, an activitypub outbox, etc. — you might need to use a strategy pattern to make this pluggable.
