Piefed community tags
Technical Discussion
3
Post
2
Autori
2
Visualizzazioni
-
Hi rimu@piefed.social did Piefed.social update recently to include community tags? I recall this was announced awhile back but it only just started breaking on NodeBB.
"tag": [ { "background_color": "#99c1f1", "blur_images": null, "display_name": "Feature request", "id": "https://piefed.social/c/piefed_meta/tag/198", "text_color": "#000000", "type": "lemmy:CommunityTag" }, ... ]I should point out that there's nothing wrong with the JSON. NodeBB's naive logic just expected every object in
tagto have anameproperty, which your community tags do not, so things exploded :cold_sweat: -
Oh hey @rimu, what's the story behind the color attributes? Does other software besides PieFed use them, is there an FEP?
It's way down on my to do list, but I've still got a brain cell or two dedicated to declarative federated profile accent colors. @hollo has configurable profile colors, but doesn't federate them yet AFAIK.
-
Oh hey @rimu, what's the story behind the color attributes? Does other software besides PieFed use them, is there an FEP?
It's way down on my to do list, but I've still got a brain cell or two dedicated to declarative federated profile accent colors. @hollo has configurable profile colors, but doesn't federate them yet AFAIK.
julian@fietkau.social IIRC I think Rimu wrote an FEP for it but it was not submitted through the official FEP processes.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
julian@fietkau.social IIRC I think Rimu wrote an FEP for it but it was not submitted through the official FEP processes.
-
Oh hey @rimu, what's the story behind the color attributes? Does other software besides PieFed use them, is there an FEP?
It's way down on my to do list, but I've still got a brain cell or two dedicated to declarative federated profile accent colors. @hollo has configurable profile colors, but doesn't federate them yet AFAIK.
-
Hi rimu@piefed.social did Piefed.social update recently to include community tags? I recall this was announced awhile back but it only just started breaking on NodeBB.
"tag": [ { "background_color": "#99c1f1", "blur_images": null, "display_name": "Feature request", "id": "https://piefed.social/c/piefed_meta/tag/198", "text_color": "#000000", "type": "lemmy:CommunityTag" }, ... ]I should point out that there's nothing wrong with the JSON. NodeBB's naive logic just expected every object in tag to have a name property, which your community tags do not, so things exploded :cold_sweat:
-
@silverpill oh, I see. I must have missed the context for the discussion, sorry. :)
@technical-discussion @julian @grishka
-
@mariusor This is basically what my FEP currently recommends: you can trust embedded anonymous objects, fragments and object of Create. Everything else should be authenticated using a different method (e.g. fetched from origin).
-
@julian I'm not sure what "blindly reflecting" means, but it's at most as vulnerable as using iframes and way less than trusting CDN scripts.
The way GoActivityPub uses C2S is through clients that validate and sanitize content that they serve back to users, or store in a persistence layer.
Personally I don't understand why it would make it different than S2S?
Are you thinking about C2S from a JavaScript client perspective only?
-
mariusor@metalhead.club silverpill@mitra.social C2S brings with it a whole other rat's nest of security concerns.
In an S2S context same origin content ought to be trusted as having been verified. I'd argue a server blindly reflecting received AP content is a vulnerability.
-
> - Recipient: trust embedded object only if the wrapping object has the same owner.
@silverpill no, dereference object and use that instead. The canonical version of an object is the one retrieved from the originating service.
Mastodon has popularised this behaviour where embedding collections (like your replies) is done by servers in the name of "optimizing" for request counts. But this introduces issues and personally I think it's a "code smell" for ActivityPub. Embedding should be restricted to anonymous objects. When an ID exists it should be used most of the time.
