Notices by Toast :chaos: (toast@mk.toast.cafe)

@clacke@libranet.de the correct behavior is to send the delete to basically everyone, since you never know where it might have been federated to (via fetches or relaying)
other msky variants only send it to your followers

as for other software, all msky variants cascade deletes
so let's say you have a thread of notes A -> B -> C -> D
on a deletion of B, all msky variants will trigger a deletion of C and D as well

starlight v3 is out: https://github.com/CosmicToast/starlight/releases/tag/v3
brblack has been renamed to black, but is still the foreground.
Instead, there is a new brblack that is gray.
This is because most terminal applications assume that black == background and use brblack for a sort of gray.

@Johann150@genau.qwertqwefsday.eu @mia@movsw.0x0.st there's the sfr extension thing but it's reading someone else's code, and as of currently I have more urgent (to me) things to do ? (like improving blocks further, secure mode, FOAF, bubble tl)

#FoundKey release v13.0.0-preview2 is OUT

It's highly recommended you update to it ASAP because of two highly important features:
* outgoing deletes now work properly (they're sent out to ALL KNOWN instances)
* instances are flagged as dead automatically (no more manually selecting "stop sending activities to this instance") for the benefit of your job queue

This makes #fkey the first (to my knowledge) fedi software with optimal and correct handling of both incoming and outgoing deletes (e.g threads)!

There are many other new and useful features as well.
You can look at the full changelog here for the rest of them.

@xjix what'd I do :0

@helene@p.helene.moe the issue is that home/social/etc timelines have to filter on channels

@volume@fr13nd5.com what the hell are you talking about

to elaborate
the streaming and timeline APIs are significantly complicated by channels
if they're not useful, it could lead to significant simplification of that part of the codebase

@helene@p.helene.moe @puniko@mk.absturztau.be yeah, which is why I said antennae cover the use case, roughly (minus the hiding it from other timelines bit

@puniko@mk.absturztau.be making them federate is kind of awful as they are now + there are actual interoperable group proposals around that would be incompatible
also no because channels don't allow other posters

@puniko@mk.absturztau.be it definitely seems like lists and antennae cover the use case to me tbh + they actually federate

@nik@letsalllovela.in @ARCONITE@letsalllovela.in server toast (the burning servers toast me

coming soon :ai_smug:

this was a group effort!
I mostly helped by making it work properly for the local instance ticker (which involved adding the configured version to the client metadata)

hello new #foundkey #fkey feature

@norm@misskey.biribiri.dev I'll see what the overall consensus is, but that's what I'm thinking also
they probably need better UX though

foundkey 13.0.0-preview1 has been tagged btw
feel free to run it!

Here is a quick guide on how to follow "stable releases" using the main+tag system.git clone https://akkoma.dev/FoundKeyGang/FoundKey cd FoundKey # use whatever branch name you want # I'm using toast.cafe in this example git checkout tags/v13.0.0-preview1 -b toast.cafe # now you have a branch that you can do things with! # once a new release is out... git fetch -t # get the new tag # merge the tag in! for easy reverts you can also choose to squash everything, it's up to you! git merge tags/v13.0.0-preview2 --squash # you are now on the "next" release