gRegorOdder, the JWT encoding specifies HS256 as a supported algorithm, encodes with that, but then decoding it's an UnexpectedValueException "Algorithm not allowed"
btremI can see the case for flexibility in html semantics, but I think using <abbr> for an emoji seems too far a stretch. Like I wouldn't use <abbr> for a company logo with the title for the company name.
btremAnd I think one must consider what happens when you leave code for several months, or years, and come back. I think *I'd* be confused by seeing <abbr> tags around an emoji. Which means fixing or changing something is just a bit harder. YMMV and all that.
[tantek]right, so clearly I should write a blog post about how & why to semantically use abbr tags with emojis so if/when someone comes across such code they can websearch for abbr and emoji and discover a blog post explaining it
jackyand tbh that kept me away from BlueSky for a bit (despite following a lot of people, it felt like I was seeing the same thing - which was this for a while)
sknebelwhat do you mean by "adjustable by clients"? (i.e. if I read "clients" as "apps" it doesnt quite make sense to me, why would apps be allowed to adjust anything?)
aaronpkthat's not the same as allowing a user to have their own policies of what apps can do when they authorize them, it just doesn't necessarily need to be scope
aaronpkfor example, in my consent screen, I can select which channels a post will appear on when I log in to a client. I can also force a client's posts to be private or draft first
sknebeland for the scopes some of it I'd expect to happen "somehow" through the integration between the servers and the indieauth code. E.g. whatever configures your micropub endpoint to be connected to your indieauth endpoint also teaches your indieauth endpoint about the micropub scopes? if you want ot generalize that?
[tantek]btw speaking of IndieAuth and that Bluesky usernames article, should we provide advice/guidance for IndieAuth consuming sites and use of harassing/abusive terms in domain names? should we be worried (defending against) this for the IndieWeb wiki *before* it becomes a problem? (perhaps that's a #indieweb-meta thread fork)
sknebel(i.e. not just have it hardcoded in the indieauth endpoint "these are all the protocols and scopes that exist" - which might very well be easier)
sknebeljacky: yeah, I think that bit is in the undefined space of "server and auth endpoint know about each other and how to talk", and if you wanted to make it pluggable that would be the place to add it
[tantek]and it's worth prototyping some sort of mitigation ASAP on the IndieWeb wiki and using the experience from that to document guidance for IndieAuth client apps in general
[tantek]yes, some draft guidance on /IndieAuth would be good too, linking to a known list (like whatever BlueSky checked into their OSS repo for example as a start)
[tantek]GWG, short version, if someone with (anti-semitic-phrase).me "liked" one of your posts and their domain showed up as a link on your post, how would you deal with it?
[tantek]sknebel it is different than moderation because it is blocking. as in, you never want to even have to go through a moderation queue of such garbage.
GWG[tantek]: I don't think it does, which is an enhancement. I mentioned I want to look at how we could enhance the built in stuff as opposed to replace it, because that causes conflicts. IndieAuth, for example, is already conflicting with other login plugins much as I tried to avoid it
gRegor, shoesNsocks, jacky and gRegorLove_ joined the channel
sknebelbut I would not be surprised if someone remembered "feeds? rss, right?", went to look up RSS and there we are (even though most people used "RSS" generically to mean RSS or Atom)
btrem(sigh) I changed the sort order of an array of posts from reverse chronological to chronological because it seemed more intuitive. And broke a piece of data, because I was getting index 0 and I need the last index. :-(