#Holos will be available on #FDroid soon, and we hope to get more feedback to improve the project. While #Fedilab uses server APIs, here we can do much more to improve your #Fediverse experience with an #ActivityPub server running directly on your device. We already introduced E2EE DMs and personal identity. We will go further with automatic deletion, even at posting level. You decide the availability of a message. We will also work on interaction controls from #GoToSocial.
gotosocial
After quite some time, I’m finally ready to share this.
MastoBlaster is now available in public testing on TestFlight.
It is a lightweight, privacy-first Fediverse client for iOS, built around a simple idea: fast, small, predictable behavior, and first-class support for snac.
What makes it different:
• snac-first by design, not "compatible by accident"
• Works with all Mastodon API compatible software, including Mastodon, snac, GoToSocial, Akkoma, and others
• EXIF stripping on upload (HDR and orientation preserved)
• Optional on-device alt text generation via Apple Intelligence for your uploads and for images in your timeline
• Markdown posting for snac
• Granular notifications, grouping, multi-account
• Blocking and moderation tools
• Very small footprint, very low RAM usage
Alt text generation happens entirely on device via Apple APIs on supported hardware. Nothing is sent to external services.
It is built around my own workflow and priorities. It may not be for everyone, and that is perfectly fine.
Important note:
MastoBlaster will always be free for BSD Cafe users, illumos Cafe users, and for anyone connecting to a snac instance, including self-hosted ones.
The app is already usable, but this is still a test phase. I am looking for feedback, bug reports, and real-world usage insights.
TestFlight link:
https://testflight.apple.com/join/Pkxa5R1k
Stay tuned.
#MastoBlaster #iOS #Fediverse #Mastodon #snac #snac2 #Akkoma #GoToSocial #ActivityPub #OwnYourData
Edited 1d ago
RE: https://mastodon.social/@dansup/116094075872982176
Totally agree! This is exactly what #GoToSocial's interaction policies already handle with Accept/Reject for replies. The missing piece is retroactive rejection. When a reply was auto-accepted by the policy and you later block the author, the server should send a Reject on the original Create activity to unlink it. Extending their framework would be the cleanest path.