Piefed community tags
Technical Discussion
8
Posts
5
Posters
56
Views
-
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.
-
@rimu It looks like
display_namewas changed tonamein Lemmy: https://github.com/LemmyNet/lemmy/pull/5976 -
The change to how post flair federate was done with the 1.2 release. We tried to mirror the json structure as it currently stands with the planned lemmy 1.0 release (schema here).
We have some extra fields for indicating the text color and the background color of the post flair as well as whether the flair should apply a blur effect to the post preview (for things like spoiler posts). Lemmy hasn't yet finalized how they will schematize the color properties yet. You can see and contribute to the ongoing discussion here.
We will be updating our schema as theirs comes more into focus to try to keep the interop and transition as smooth as possible. If you want to see an example of an existing community that makes heavy use of post flair, you can look at !fediverse@piefed.social.
-
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.
-
@rimu Thank you! 🙂
I took a look at the source code too and it seems to expect CSS hex notation (either 6-digit RGB or compacted 3-digit form).
One of the things I've been agonizing over is how to allow richer CSS colors, HDR etc. It'd be a short spec to be like “just do anything https://drafts.csswg.org/css-color/#color-syntax allows” but I'd want to give non-browser-based clients some sort of 8-bit RGB fallback. And all that without exploding the complexity. 😓 Will keep thinking on it.
-
@rimu Thank you! 🙂
I took a look at the source code too and it seems to expect CSS hex notation (either 6-digit RGB or compacted 3-digit form).
One of the things I've been agonizing over is how to allow richer CSS colors, HDR etc. It'd be a short spec to be like “just do anything https://drafts.csswg.org/css-color/#color-syntax allows” but I'd want to give non-browser-based clients some sort of 8-bit RGB fallback. And all that without exploding the complexity. 😓 Will keep thinking on it.
Another tricky aspect of this is different clients have all kinds of different designs and colors so depending on the situation the tags could look garish and crazy. But on the other hand a bit of crazy is fun.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@bentigorlich@gehirneimer.de in the relevant issue in Mbin's issue tracker raises a wording concern: "resolvable context" is an unfamiliar term to those who have not read through FEP 7888.
I will update the FEP to make this definition more explicit.
https://github.com/MbinOrg/mbin/issues/248#issuecomment-3741019183
-
Tagging relevant parties:
@rimu@piefed.social of Piefed @nutomic@lemmy.ml of Lemmy @bentigorlich@gehirneimer.de and @melroy@kbin.melroy.org of Mbin
-
The submission of the FEP and timing of this post are intentional as there are now two implementors supporting (part of) this FEP.
NodeBB as of v4.7.0 Piefed as of v1.5As the implementors work through any issues, the FEP and this topic will be updated to reflect those changes.
-
Threaded applications often have the need to move and remove content between groups/communities for curation purposes (i.e. resolving miscategorization, spam, etc.)
This is an extension of the Resolvable Contexts tree of FEPs.
The FEP draft has been submitted for review. In the meantime, it can be viewed here: https://github.com/julianlam/feps/blob/fep-f15d/fep/f15d/fep-f15d.md
-
Client reputation isn't really something you can track and share in a decentralized network without introducing some centralisation. You could try to do web of trust style things, but that would mean writing a record that publicly says "good client is good", but then a malicious app could just write that record on sign-in: how many iOS apps nag you for a positive review? Particularly with somewhat dark patterns of "are you enjoying ? Yes / no" where "no" pushes you to the app's feedback and yes pushes to write a review, trying to deliberately avoid negative reviews.
The other downside of publicly disclosing which clients you use is that it tells attackers where to look for security exploits, because now you can pick a set of targets and try to attack the software they use.
Raw usage numbers also doesn't help because a bad client can quite easily become viral, see for example Cambridge analytica, who iirc used games to gain access to sensitive data.
You'd also need moderation tools that can moderate clients in some sort of meaningful way — that's near impossible for dynamic client registration. That's why we wrote the CIMD spec. A large Mastodon server usually has 10-20x the number of registered clients as number of accounts.
Things that can add up to trust are things like:
privacy policies & terms of service client_uri (website) matching the client metadata (requires some crawling) client authentication mechanism (public client vs private_key_jwt auth) scopes/authorization requested being fine grain enough, instead of asking for full unrestricted access.But OAuth security and trust models are complex and generally proprietary
-
@evan
Sounds good!I suppose it would be useful to be able to specify the version too so that you may ban a known buggy version of a client or any version prior to a known CVE fix.
It could also be useful to make those lists shareable so that a new Fedi instance can start with something if they wish to.
-
I'd suggest that there are two parties that should get to decide what is a good or bad client:
The ActivityPub user who uses the client. The administrator of the server that the ActivityPub user uses.I think there's a third group, which is other admins, developers, and users, who share similar values with the user and the admin. They may have information to share with the user and/or admin.
I don't think these values are universal, so I don't think we need a universal reputation. But I can give what I think are bad things for an API client to do.
Generating activities on behalf of the user that don't match the user's express or implied intentions. For example, if the user logs into a client app, and it posts a public message, "I think this client app is the best and everyone should try it!" Extracting the user's data for reasons that the user wasn't informed of. For example, a client app that copies all your private messages to cloud backup controlled by the app developer. Abusing public or private resources, even if the user intends to abuse. For example, a client app for spamming, or a client app for brigading.I think there are a few signals that could identify what I would call "bad" clients:
User complaints would be the biggest Complaints from other users about the user's behaviour when using the app Security researcher reports
-
@evan brilliant!
