Notices by Kaity A (supakaity@blahaj.zone)

A few people have asked us now about the future of Hajkey, given the recent changes with Calckey becoming Firefish and the Iceshrimp fork of that. So I thought I'd make a post, now that I can type again and let you know where we're at.

I have been taking a small break from adding new features to Hajkey recently because my left arm has basically been useless for the last month after breaking it, but I'm now able to partially touch type again, and my arm is incrementally better each day.

However my reticence with writing new code has been going on for a bit longer than that.

I was in a dev chat room with a few devs, trying to pursuade that the safety of a minority group is paramount whilst trying to justify the addition of a new safety feature. I was tyring to make the point that a feature which may initially confuse some people is worth it if we protect just one minority person. I also tried (without luck) to address the (valid) concerns about how to implement the feature with minimal potential for confusion.

However, I feel like while the majority of minority people present in the room agreed, my point was ultimately worn down and overruled by a single person who I feel didn't understand what such a feature would mean for the safety of those needing protection.

I am ashamed to say that I felt a lot of disempowerment and lost a lot of forward momentum when that happened, questioning my own compass which said that I should push ahead, but pushing ahead without an implementation in other instances would make my new feature a non-starter.

I don't see a lot of diverse fediverse projects around which focus on security features to protect the vulnerable or that have dev leads that have experience with existing in a society with a greatly diminished privileged status. This means that they are not as concious of the features that are important to us and other underprivileged or minority groups.

I am proud to run one myself, and as a female and transgender person (and whilst acknowedging my own significant privilege), I think that gives me somewhat of a unique and valuable perspective, so it excites me to see that there's a new project (Iceshrimp) starting, focussing more on security and safety and less on flashy new sparkles and bling. I feel like this will ultimately be a good thing for the fediverse.

In the FOSS world, diversity is, like in the real world, a fantastic thing. It drives innovation, allows greater choice, avoids stagnation, vendor siloing, narrow minded thinking and generally inproves the overall health of the entire ecosystem.

So I congratulate @april@donotsta.re on their new project. I'm looking forward to great things from Firefish and Iceshrimp, both of which are rich with diverse developers. While Firefish can focus on the flashy usability and experience tack, Iceshrimp can help fill the sorely needed safety aspects. The good features from both will help improve the quality of experience and ultimately our end users will benefit.

As far as Hajkey is concerned, we'll still be our own fork, still doing our own little thing, but we will be directly downstream of Iceshrimp and will be pushing our changes back upstream to the 'shrimp.

We made this choice as we feel that this project more closely aligns with our overall goals and has less focus on the commercial/sponsorship side of things which we are uncomfortable with. Also this way the trademark issue (while not a blocker for us) is something we don't have to worry about biting us in the future.

We're also not planning a name change at this point. We like Hajkey as a name and don't currently see a compelling reason to change that.

@toni @maikelthedev @ada @jdp23@calckey.social @kainoa@calckey.social I'm inclined to agree. If @ada agrees I think we should change that behaviour in Hajkey.

@Jain@blob.cat @ada@blahaj.zone @cody@misskey.codingneko.com Again it's going down the path of focusing on the "bad people", but I'll indulge you a little.

Does using software that doesn't support it make you a bad actor? Not necessarily. It may makes you an unaware user. And that's not necessarily bad. Or you may be a user that's deliberatley using old software to bypass these restrictions. It's not an uncomplicated situation, and someone may chose to block you if you keep posting after being informed, that's dependent upon the two user involved. If that user keeps doing it, maybe it goes up the chain. We already have moderation processes to deal with these scenarios.

Is it possible in the current framework? I don't believe so. I've done substantial research into this, so I'm not just pulling this out of nowhere.

Will it harm more than it solves things? There's significant harm being done at the moment, and no movement on solving the issue. Is this the right answer? I think it's a good start.

Is it user friendly and understandable? Explaining the advisory nature of this feature, documenting it and raising awareness of it is a big part of the implementation that needs substantial consideration.

Unfortunately automatically parsing a profile page is a very poor way to determine if I should show a specific federated post on my instance to users who are entering a search term.

I'd prefer to be given a clear direction on if a certain user can see your post in their search results rather than guessing and even worse guessing wrong.

@Jain@blob.cat @ada@blahaj.zone @cody@misskey.codingneko.com Moreover, it has not yet been discussed to what extent the answers to a thread should take over these flags. I can well imagine that especially the restriction that not all can answer is generally very difficult. You would either have to accept that the replies have their own/different values for the flags, or you would have to share whole follower/blocklists to be able to restrict a post really cleanly.Just like you can't expand visibility on replies, you shouldn't be able to expand rights on replies. There's a whole bag of worms waiting under the "but should you be able to futher restrict on replies" and the answer is probably yes... but that's gonna make my brain sore when I start thinking about it...

@Jain@blob.cat @ada@blahaj.zone @cody@misskey.codingneko.com I actually don't want to get dragged into the enforcement argument.

You're absolutely right in that it's not going to be possible to stop actors deliberately doing bad things on the fedi.

The whole point is that at the moment, as a good actor on the fedi. I don't know your wishes, because there's no way for you to tell me that you don't want me to be able to full-text search your posts, or that you're not interested in my opinion on a particular topic if I wasn't mentioned.

How do I be a good actor if I don't know how?

Well, we give you a way to tell me.

@cody@misskey.codingneko.com @Ada@blahaj.zone the answer is that we don't plan to enforce it.

These are advisory mechanisms that allow you to express your wishes.

We want to be good citizens, we want our users to be able to be good citizens. At the moment there's no real way for someone to tell us how they want their content treated.

We will apply them on our instance.

Hopefully other well behaved instances will as well.

Deliberately misbehaving has other recourses available.

We will of course highlight (or lowlight rather?) bad actor's actions in the thread view and probably add options to toggle them hidden, collapsed or shown (depending on user preferences), on the main instance, and maybe not even include their actions in the conversation list for onward federation.

But really, enforcement is not the point at all. At the moment there's no way for the author to even tell us any of this stuff so that good actor's can act good.

Preface: This is a long, technical post so I apologise in advance. Please avert your eyes if such things offend you.

Hi everybeings!

Overview

@Ada and I have discussed many areas where we see problems in the way the Fediverse currently works and where would like to see improvements made to improve safety of the fediverse.

Safety on the fediverse is one of the topics we hold most dear.

One of these areas (and one that has recently garnered a lot of attention) has been in the area of full-text search, and despite the option for account-wide no-crawl options in many pieces of fediverse softwares, this option is not-federated, non-specific, non-granular and not-for-purpose with regards to fediverse searching. It's specifically designed and worded for crawler bots at a html scraping level, and while we could repurpose it for fedi-searching, it just doesn't feel right or quite fit.

There's been a lot of talk on a lot of different levels out there, but nobody's come to a concensus. A lot of people are talking about how we should do it and what standards we should use, and generally making the whole concept a lot more complicated than it needs to be.

In this post, I want to share with you some of the ideas that I've gathered through my research, and implemented in a way that is simple enough (KISS), not overly complicated (YAGNI) yet still fit for the purpose I need as both a software engineer and an instance admin, and that anyone accessing the content will need.

The idea in sharing this is not to convince me that it shouldn't be done, or to create the absolutely most perfect solution possible that's going to take 20 years to build and will be outdated by the time we get there.

This will be getting built and going out in weeks, not months, not next year. It's needed now. This is my current plan how to implement something we needed months ago, now. This is your chance to change my mind and help refine this plan before I start really coding it up.

Technical/implementation details

A lot of these options will be settable as a default value in your settings as well as at an individual post / file level during composition or afterwards at editing stage.

In terms of inbound federated AP objects which do not support these new fields, we will try to infer the intent based off existing AP fields and other metadata when present.

Specifically, we will be using the Mastodon Account Lookup API (GET /api/v1/accounts/lookup?acct=) to get and store the noindex flag during actor creation/refresh. This will also allow us to put the noindex meta tag on any HTML pages containing that actor's posts.

Searchability

So you don't want people to be able to search for you. But is that everybody? Maybe you want your followers to be able to find your posts? Maybe the people you mention should be able to find your post? What about actual users on your local instance? Maybe a particular post you never want to appear in searches? Maybe a particular post you write contains stuff you want everyone to see?

We will be adding a global default and per-post override federated in AP as hk:searchableBy which will be settable to public, private or a combination of followers, mentions or local. This is different to the currentvisibility in that you can have a public visibility post that is searchable by followers and mentions for example.
{ ... "searchableBy": ["followers", "mentions"] }
Interactivity

The other problem is that at the moment you can't control who can reply, boost, vote and/or react to your posts.

To this end, we will be adding per-post overrides federated in AP as hk:canReply and hk:canInteract which will allow you to specify like on searches a combination of public, private, followers, mentions and local for replying to, and boost, voting or reacting to your posts respectively.
{ ... "canReply": ["mentions"], "canInteract": ["public"] }
Licensing

Licensing and attribution can get pretty tricky. On the fediverse, we're assuming that if you're making a post, then you have the rights and willingness to let the content be federated. If you didn't you wouldn't post.

However posting content sometimes requires you to provide the license and attribution that you're using along with the content. At the moment there's no reasonable or standardised way to provide this information on an image or in a post, thus you're in breach if you post a CC-BY licensed image.

So to alleviate this, we will be providing 2 federated AP fields hk:licensing and hk:attribution. The licensing field will contain the URL of the license under which the content is being shared and the attribution will contain any links to the source content/s and/or creator/s.
{ ... "license": "https://creativecommons.org/licenses/by-sa-nc/4.0/", "attribution": [ "https://github.com/supakaity/icons" ] }
Crawlability

So crawlability is about indexing of the content by external parties whether they be search engines or fedicrawlers. It will provide a per-object level flag under the AP field hk:crawlable that lists whether the item may be processed by a bot. The possible values are true or false.
{ ... "crawlable": false }
Quotability

Now this is a controvertial one. Sometimes people out there don't mind their posts being boosted, but don't want them to be quoted. You know what we say? If you don't want your posts quoted, we should respect that and not allow people to quote you. So we'll be supplying an AP field hk:canQuote that lists who can quote your posts using the same combination of actor types as above.
{ ... "canQuote": ["followers"] }

@kainoa@calckey.social show off!

As part of our efforts to make the fedi a safer place for our users, we've got some quality of life changes inbound around content warnings.

One goal of this change is to make it more obvious that content warnings are present on a note, so in this case we have the regular CW prefixed with a warning shield and enboldened to make it obvious it's a content warning and not just text. (image one)

Secondly there's now an option in general to enhance this warning with an outline and inverted header color.

The setting is under Content Warnings on the Appearance settings page (Or under General in Calckey). (image two)

Turning on this option makes CWs much more noticeable. (image three)

Finally, previously if you had a CW on a boost (possible if you quoted, added a CW and then didn't have any text), the UI would create a CW'd boost, but not display the CW, and just display it as a regular boost. You could of course turn it into a quote by typing some random text, but quotes are displayed differently and appear in the replies as well.

So there's two changes.

1: Fix the UI so that boosts with a CW, but no CW in the original boosted post are now displayed with the CW from the boost..

2: There's now a handly little "Boost with CW" in the boost menu to make it super easy when you have a post that you'd really like to boost, but feel like it deserves a CW.

I've added a short capture demonstrating the whole process.

I have a few more safety related ideas that I will implement over the coming weeks as well (after clearing them with the boss @ada first, of course!)

Enjoy and stay safe, my precious people!

:blobcat_hug:

@thatonecalculator@stop.voring.me Oh no! Incoming merge hell.