▲ 127 ▼ We have to solve the money problem! (blenderdumbass.org) submitted 1 year ago by blenderdumbass@lm.madiator.cloud to c/fediverse@lemmy.world 174 comments fedilink hide all child comments
[–] rglullis@communick.news 2 points 1 year ago (1 child) Yeah, I am 100% convinced that we need to rethink AP to make it less dependent on servers. permalink fedilink source parent hideshow 2 child comments replies: [–] benjhm@sopuli.xyz 1 point 1 year ago (1 child) I agree with most of what you say. I'm a long-time fan of calculating more complex things client side, as you can see from my climate model (currently all calcs within web browser, evolved from java applet to scalajs). Also, in regarding social media, keeping the data client side could make the network more resilient in autocratic countries (many), and thelp this become truly a global alternative. On the other hand, some 'trunk' server interactions could also doing more not less, bundling many 'activity' messages together for efficiency - especially to reduce the duplication of meta-info headers in clunky json, and work of authentification-checking (which I suppose has to happen to propagate every upvote in Lemmy?). permalink fedilink source parent hideshow 2 child comments replies: [–] rglullis@communick.news 2 points 1 year ago bundling many ‘activity’ messages together for efficiency - especially to reduce the duplication of meta-info headers in clunky json Seems like an optimization that is not really needed. The data format is not really the bottleneck, there are ActivityPub relays that can send messages in bulk and ActivityPub is built on LinkedData, which means that there plenty of powerful libraries in most languages that can parse and produce JSON in a way that keeps application developers with a consistent semantics. The more people try to change the data format in the sake of "efficiency", the less portable and useful it would be. and work of authentification-checking (which I suppose has to happen to propagate every upvote in Lemmy?) Yes and no. Most of the current software do authentication by using HTTP Message Signatures, so after you fetch the actor's public key every request is authenticated by seeing an HTTP header, which makes it no different most common authentication schemes. permalink fedilink source parent
[–] benjhm@sopuli.xyz 1 point 1 year ago (1 child) I agree with most of what you say. I'm a long-time fan of calculating more complex things client side, as you can see from my climate model (currently all calcs within web browser, evolved from java applet to scalajs). Also, in regarding social media, keeping the data client side could make the network more resilient in autocratic countries (many), and thelp this become truly a global alternative. On the other hand, some 'trunk' server interactions could also doing more not less, bundling many 'activity' messages together for efficiency - especially to reduce the duplication of meta-info headers in clunky json, and work of authentification-checking (which I suppose has to happen to propagate every upvote in Lemmy?). permalink fedilink source parent hideshow 2 child comments replies: [–] rglullis@communick.news 2 points 1 year ago bundling many ‘activity’ messages together for efficiency - especially to reduce the duplication of meta-info headers in clunky json Seems like an optimization that is not really needed. The data format is not really the bottleneck, there are ActivityPub relays that can send messages in bulk and ActivityPub is built on LinkedData, which means that there plenty of powerful libraries in most languages that can parse and produce JSON in a way that keeps application developers with a consistent semantics. The more people try to change the data format in the sake of "efficiency", the less portable and useful it would be. and work of authentification-checking (which I suppose has to happen to propagate every upvote in Lemmy?) Yes and no. Most of the current software do authentication by using HTTP Message Signatures, so after you fetch the actor's public key every request is authenticated by seeing an HTTP header, which makes it no different most common authentication schemes. permalink fedilink source parent
[–] rglullis@communick.news 2 points 1 year ago bundling many ‘activity’ messages together for efficiency - especially to reduce the duplication of meta-info headers in clunky json Seems like an optimization that is not really needed. The data format is not really the bottleneck, there are ActivityPub relays that can send messages in bulk and ActivityPub is built on LinkedData, which means that there plenty of powerful libraries in most languages that can parse and produce JSON in a way that keeps application developers with a consistent semantics. The more people try to change the data format in the sake of "efficiency", the less portable and useful it would be. and work of authentification-checking (which I suppose has to happen to propagate every upvote in Lemmy?) Yes and no. Most of the current software do authentication by using HTTP Message Signatures, so after you fetch the actor's public key every request is authenticated by seeing an HTTP header, which makes it no different most common authentication schemes. permalink fedilink source parent