A short blog post on NMail/NostrMail - an attempt at making decentralized/e2e encrypted email on the Nostr protocol that's backwards compatible with regular email.
Well, I might have just had a 'productive' all night gaming session followed by sleeping into 4PM. Got called to do a set of 9PM-9AM shifts, because of some rather high winds, at the local power company I recently started working at. Wish me luck.
There have also been rumblings of implementing Zot/Nomad’s nomadic identities, although that effort seems to have stalled out. Finally, some platforms like Streams/Hubzilla (Nomad & Zot respectively) offer limited user account ownership, bridging internally to ActivityPub. However, if a server went down, the user would retain their Nomad/Zot following while losing their ActivityPub followers/following.
It didn't stall. Streams and its successor Forte support ActivityPub-native nomadic identities.
Oh, cool, thanks for the heads up. Just to clarify, though, the nomadic identities on ActivityPub is still being developed, although no projected time frame of pententually becoming part of the spec right?
Some aspects of it are still being developed, but overall I think it is a proven technology. Forte is a project from the same person who invented nomadic identity and built Streams, Hubzilla, Friendica etc.
Nomadic identity may never become a part of the official spec because ActivityPub was published in 2018 and haven't received any updates since then. However, ActivityPub now evolves through FEPs (Fediverse Enhancement Proposals), and nomadic identity specs are published as FEPs (for example, FEP-ef61).
Two photos of the lunar eclipse this morning. Both are unedited, one from my personal phone (Pixel 8a) one from my work phone (iPhone 17). Taken through a family member's telescope, but used digital zoom on the pixel.
Friendica is showing the images, but locally here on Holos they seem to be missing. Not sure if it's not showing up because the client is in beta or because the relay is in beta. If you can see them, then don't worry about the link, they're the exact same photos as I put in the parent post.
We're happy to announce a long-term partnership with Motorola. We're collaborating on future devices meeting our privacy and security standards with official GrapheneOS support.
This is the best news I've heard recently. Atleast now app developers will ditch the Google Play Integrity crap and provide first class support for alternative platforms.
really hoping this is gonna be cheaper than a pixel at current prices cause that'll probably be a killer for me if a graphene OS phone costs 900 dollars
It was your point that Motorola is the partner because they want to make money. If the people are only able to buy their phones after some others already did and now resell them, I don't See how they profit. People buying the high Ende devices for Graphene may exist AS well but in WhatsApo rate
Lots of these are giving up even more security features.
> hardened_malloc, malloc-ng, or mimalloc-secure
These aren't the same classes of allocators at all. Neither the musl malloc or mimalloc is a hardened allocator. mimalloc is performance focused and musl's is focused on low memory usage.
> What are your thoughts on what to do in case the day comes that Google kills AOSP?
What about when IBM decides to kill systemd, GCC and GNOME?
@lumi @alexia The current default software stack for desktop Linux is kind of terrible and the lack of coherent threat model or proper ecosystem of sandboxed applications are major issues with desktop right now. What I am still questioning is whether it is even possible to make a proper competitor to ChromeOS (if we ignore the hardware insecurity of basically all PCs).
So example software choices: systemd -> dinit or s6 sudo -> s6-sudo (setuidless) glibc -> muslc glibc malloc or jemalloc -> hardened_malloc, malloc-ng, or mimalloc-secure (which supports more CPU architectures) bubblewrap (sandbox used by Flatpak) -> #syd (it's written in Rust, has many important exploit protections, and can even be the user login: g
... Show more...
@lumi @alexia The current default software stack for desktop Linux is kind of terrible and the lack of coherent threat model or proper ecosystem of sandboxed applications are major issues with desktop right now. What I am still questioning is whether it is even possible to make a proper competitor to ChromeOS (if we ignore the hardware insecurity of basically all PCs).
So example software choices: systemd -> dinit or s6 sudo -> s6-sudo (setuidless) glibc -> muslc glibc malloc or jemalloc -> hardened_malloc, malloc-ng, or mimalloc-secure (which supports more CPU architectures) bubblewrap (sandbox used by Flatpak) -> #syd (it's written in Rust, has many important exploit protections, and can even be the user login: gitlab.exherbo.org/sydbox/sydb…) GNOME or KDE -> XFCE (when their new Rust Wayland native WM is finished) gnutils -> *BSD or uutils
The issue of course with most of these alternatives is that they are separate projects and therefore dont have the same goals, methods, or threat models. Also most of these projects are written in C which does not help at all. Also there is of course the lack of a proper chain of trust from the hardware to loading the kernel and userspace.
It may just not be reasonably possible to provide a alternative without millions of dollars of funding and a decade of development. It would be nice for there to be an alternative to AOSP/ChromeOS or even MacOS for desktop computing which actually takes security seriously. It doesnt even need to have be completely on par when it comes to security, just do better than current Linux distros (not a very high bar).
What are your thoughts on what to do in case the day comes that Google kills AOSP?
@GOKUSHRM Our partnership is Motorola is not exclusive and we're fully allowed to partner with other OEMs. However, we don't currently have the resources to partner with additional OEMs and it will likely be a while before we do.
Partnerning to make smartphones with a company which recently discontinued their smartphones doesn't sound workable. The point is also mainly getting an OEM to raise their security to meet our requirements rather than getting an OEM to sell devices with GrapheneOS.
@GOKUSHRM We're not going to lower our standards to expand device support so if they can't or won't meet the requirements then there's not much to talk about. That's why most of the smaller OEMs are ruled out because they can't afford or are at least unwilling to invest in the required security including long term updates and a high end SoC. The device itself doesn't have to be high end as a whole but the SoC needs to be high end to get long term support and the current era security features.
@GOKUSHRM SoC licensing is very expensive especially for the latest and greatest. No one really wants to use a flagship SoC in anything but a flagship device.
doing PGO on a development build (considering the guide is meant for developers) is insane IMO
that's something one would do on their final fully optimized build, not for development, and specially not if the need to debug anything in native code is there...
from what i recall in my encounters with googlers: it's pgo.
from my own experience on gentoo lto adds around 30% memory pressure and pgo adds around 50%, compile time is mostly unaffected with lto but pgo quadruples it.
meaning you could run with less memory, by reducing the amount of parallel builds, except that would make the already long 6 hour build time increase close to exponentially
This entry was edited (Tuesday, March 3, 2026, 11:15 AM)
It has a package manager and has out-of-band updates to the APEX and APK components along with separate updates for boot, vendor and system images. Most of the core userspace OS is in APEX modules now.
also keep in mind each compile thread uses memory. blender rn uses like 30 gb to compile because i'm giving it 24 threads, especially when it comes to the render kernels bit since it's a single giant file.
It's the number of logical cores which determine the number of jobs by default. In general, Android builds should have 2GB per logical core unless the number of jobs is lowered.
note that, as i mentioned on the thread before, back in 2019 i tried to build it on a 7th gen i7 (so 4/8 c/t) with 16 gigs of ram and a sata ssd, after 3 days of non-stop building, i gave up
and that was when the minimum recommendations were still 32gb of ram
@rogueren @1a5cff5118d071a2c5d46534733abb9f3dcdfc41b24db0132fc20dbf01c75f78 A large portion of the GrapheneOS hardening is device specific and having device specific builds is inherently more secure due to lower attack surface and being able to specialize the builds with features like RANDSTRUCT for each device model. Aside from that, most of their devices aren't going to be able to meet our requirements. It will initially be several flagships meeting our requirements and then more over time.
@1a5cff5118d071a2c5d46534733abb9f3dcdfc41b24db0132fc20dbf01c75f78 it'll almost certainly be specific devices just due to how ARM chips work. Every chipset needs its own special drivers, which means you can't make a universal version to run on most devices. On top of Graphene being very strict on hardware feature requirement, which was part of why Pixels were the only supported phones until now
Currently things are fine with Android but Goigle keep moving toward making Android more locked from software and apps. Is not this going to be a problem to what we have now? or there is a workaround?
Looking forward to seeing where this partnership takes the project. It's been great watching continued support of the Pixel line of phones, so throwing in an official partner organization is exciting.
I don't care if it's shit, I don't care if it's 1500€, I'm getting one. Ideally more than one if it's on the budget end. A budget Moto G at the 150€ mark with GrapheneOS would be the ultimate "if i'm under risk this is becoming a foldable".
@bill88t The initially supported ones will be expensive flagships but we do want to have budget devices eventually. It's harder to meet our update and security feature requirements for those. Look at the Motorola Signature (2026), Motorola razr ultra (2026) and Motorola razr fold (2026) for an idea of how the next gen devices will likely be. These current gen ones are way closer to our requirements than previous devices but not quite there yet.
@dalias @lumi @alexia GrapheneOS has to get huge adoption and major partnerships before we can start on our much longer term goals of moving away from using a Linux-based OS as the core operating system to a more secure platform. We want to be running the current application layer part of the OS solely via virtualization eventually. We don't expect to ever make the Linux kernel and overall model it supports on top secure enough for our goals. We'll still need the AOSP-based OS for apps.
@lumi @alexia I'm excited for GrapheneOS success for people it's for, but I fundamentally don't like the Android (AOSP, not even talking about Google) model of how basically anything works. Non-Android mobile OS options are what I want. Ones where I have full root, can run a small set of trusted apps from my distro just like I would on a laptop, and where everything else runs in an extremely restricted sandbox. I don't want those relationships inverted where a gigantic pile of Java code I could never understand or build or modify is the root of authority and I just have to trust that it's going to let me do what I want.
@lispi314 @King_of_Ooo @alexia @lumi AOSP has a far larger development community than desktop Linux. There are a huge number of both corporate and community AOSP-based projects. There's a massive community of people working on all kinds of projects related to it. Desktop Linux is assembled out of a bunch of barely maintained or developed projects with one of two developers each. It has nearly non-existent systemic work on almost anything aside from systemd gobbling up components into itself.
You'll have to explain why/how IBM owns GCC. Fairly sure it's an actual FSF project.
GNOME?
RIP lol
Other than the accessibility stuff most of it I don't care much about, and with the ensloppification going on & Red Hat apparently insisting on it, it might well die anyway.
What are your thoughts on what to do in case the day comes that Google kills AOSP?
This however has real chances of happening and already has a largely closed development process with no community.
Which means it doesn't even need a poison pill contributor agreement, all the necessary rights are probably already in Google's possession for malicious license changes.
Not to mention that the main useful part of Android, the drivers & their documentation, aren't even included anyway. Everything else could be replaced by something better with some work.
@lispi314 @King_of_Ooo @alexia @lumi systemd won not because it's good but because it actually exists as a somewhat coherent basis for an OS providing the features which are wanted. It didn't have to be a sensible or good implementation of almost anything. It's far from only an init system and the overall desktop and server ecosystems are increasing based around it. All the non-tiny desktop Linux stack ports to mobile are heavily using systemd. They're bringing systemd to mobile, not Linux.
> You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.
Don't know what you're talking about. You're one of hundreds of people.
> The overwhelming majority of the BSD tooling
It has little to do with the desktop software stack. That increasingly only has an incomplete port over to BSD with a growing amount of hacks. It would just roll it back even further.
@King_of_Ooo @alexia @lumi You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.
The overwhelming majority of the BSD tooling that isn't systemd could be ported with a modest effort if systemd died. Note that I linked daemon supervisors earlier, because session managers and init systems are a lot easier to come by.
edit: Ah, my bad, I confused the subthread. You did ignore it and replied to the prior post.
@bobkmertz @greenpete @joe9nf That was most likely the modem and in some early mobiles there was zero isolation preventing the modem from simply reading all the memory bus.
(The modem should be understood as a blackbox device at the mercy of hostile infrastructure providers & "authorities", it is attack surface.)
I would hope that such isolation is part of the GrapheneOS safety requirements.
@bobkmertz@techhub.social See grapheneos.org/faq#future-devi… for our list of requirements. Cellular modem isolation has been present on even the first device we supported (Nexus 5). It predates having proper isolation for Wi-Fi / Bluetooth.
given that Moto will have to release new devices with the support, I really hope to see something "small" - iPhone 13 Mini / SE size, for less than 1000€... One can dream.
my worry is about durability. A small debri when folding it and it's game over. I love the idea of ThinkPhone, just needs a small variant! Durable, secure and small.
If they #Motorola could add #LoRa or something similar that could be a game changer.
They would offer something that other companies don't, while there is demand from users.
It also brings privacy advantages as it makes it easier to communicate undetected from cell towers. People are starting to roll out networks covering wide areas.
In addition to that, it adds an element of resilience where people could continue to communicate even when cell towers are shut down. This is especially important during national disasters and governments overreach shutting down internet access.
Whether they'll be sold at retail with GrapheneOS preinstalled as an option isn't a question we can answer yet. It mostly comes down to Google's requirements and the extent to which those can be worked around or pushed to be relaxed.
@ferricoxide @luana No, it's a much different feature than the incomplete implementation for desktops. The entirely of the firmware and operating system are cryptographically verified with downgrade protection. The secure element is used to store the version metadata for downgrade protection for the OS and efuses are used for the firmware portion of it. It's fully integrated with the A/B update system with automatic rollback until reaching the home screen successfully.
@ferricoxide @luana It's the status quo on existing devices and has been one of the hardware requirements for GrapheneOS support for many years. Verified boot was introduced on the Nexus 5X and moved to an earlier version of the current approach with the Pixel 2. We've supported it since it was available and began considering it a requirement shortly afterwards. We only supported 2 generations of devices prior to it being available which could still be locked and had the firmware verification.
This is a premature joke for the 1. April, right? 😳🤔😂🤣
Choosing a company like Motorola with it's owner Lenovo behind it for the reasons of privacy and security isn't beyond a good idea but pure hypocrisy and a punch in the guts for all of the supporters of GrapheneOS in my opinion. 🖕
@kranzkrone GrapheneOS is a non-profit organization and no money is changing hands with Motorola. What do you think greed has to do with it? There's huge demand for us supporting an alternative to Pixels and we're doing that by working with an OEM. If you want to continue using Pixels then you can continue doing so. Google and Samsung are the only top 10 Android OEMs by sales which aren't Chinese-owned. We can't force Samsung to want to partner with us and the same applies to Sony too.
The point isn’t whether GrapheneOS receives money from Motorola.
The point is the consistency of the security and trust model you advocate! 🙄
GrapheneOS often emphasizes minimizing trust in large corporations, opaque supply chains, and potential state influence.
Yet Motorola is owned by Lenovo, a Chinese company operating under a legal environment where state access to companies can be mandated.
If the argument is that users should minimize trust and maximize verifiable security, partnering with an OEM embedded in that jurisdiction raises legitimate questions.
This isn’t about “greed” but about coherence of principles.
If Chinese OEM ownership is usually framed as a risk in privacy discussions, it seems inconsistent to dismiss those concerns when it becomes convenient for hardware support.
Criticism here isn’t hostility—it’s asking whether the same standards are being applied consistently. 😉
@kranzkrone It's quite apparent you're using an LLM to generate concern troll replies. It's incoherent and lacks actual substance. We're not going to be interacting with a text generator someone has directed to waste our time and energy.
If you don't want us banning your instance and making a public post asking everyone else to do the same then remove both of these AI generated replies and stop bothering us.
Here's our policy on AI generated content for discussions:
It's indeed quite apparent that you acting out in the same way like you did in the past when the founder of GrapheneOS had a personal dispute with another somewhat prominent personality of the tech world.
If you don't want me to further investigate your toxic behavior of communication and try to framing me as the bad one, you should definitely thread lightly.
Threatening me with whatever action won't result in deleting my previous posts but instead will strengthen my personal investment in further interactions and maybe legal actions.
Louis Rossmann may would find this interesting to read too.
@kranzkrone You've moved on from posting low quality concern trolling which appears to be at least partially generated by an LLM to blatant libel and support for harassment. We haven't framed you for anything. Your replies to our thread make it clear what you're doing.
Louis Rossmann orchestrated harassment towards our founder by making many extraordinarily dishonest claims in a video where he engaged in blatant bullying. Rossmann is openly a Kiwi Farms user and is the one who involved them.
@indigoamber It has to start with those because they'll be the first meeting our update and security feature requirements. Lower end devices can gradually be supported as the improved updates and security features trickle down to those.
If I may ask, as various sources say otherwise. Will there be one dedicated model with GrapheneOS out of the box, and will the rest of the models be hardware-ready for installing this system? Or is hardware support and manual installation the only option?
@lispi314 There's a *big* difference between "sloppy security that eventually gets pwned" and "deliberately backdoored by a nation-state for the purpose of domestic mass surveillance" @GrapheneOS @publicvoit @a53bdb @lunareclipse
@publicvoit @JamesDBartlett3 @lispi314 @a53bdb @lunareclipse People have different opinions. We're going to work with Motorola to meet all of our security requirements and improve security beyond that. They're helping us with providing GrapheneOS support for their devices rather than us having to do the work ourselves. They may end up contributing more to GrapheneOS beyond that too. In the future, we can work with other OEMs. It's not an exclusive partnership but we have limited resources.
@libresoftwarelover The phones will be available in Brazil at least to install the OS yourself. We aren't sure about the availability of devices with it preinstalled yet since it's very early and we don't know which barriers may come up for that and whether it could launch in some regions but not others.
since the bootloader will trust the grapheneos keys I can't imagine why would safetynet and the other play protect mechanisms won't pass attestation (for all intents and purposes graphene would be indistinguishable from the stock Motorola image)
if that's the case I'll buy the device the moment it comes out...
@dzervas It's not going to change anything about the Play Integrity API which would be an entirely different thing. It should be able to have a green boot state (not necessarily immediate at launch) but that doesn't mean that Google Play is going to allow it because we won't have an allowlisted build fingerprint.
@dzervas Potentially but it's not something we want to bring up right now rather than focusing on adding GrapheneOS support, meeting our hardware requirements and getting some additional security features implemented. The main way they could eventually help is getting app developers to add support for using GrapheneOS either by removing the Play Integrity API (idealy) or adding hardware-based attestation permitting GrapheneOS as a replacement or alternative to the Play Integrity API.
@NewDay14 @Cambion @a53bdb Motorola contacted us about working together and we enthusiastically pursued it. We would do the same if Samsung wanted to work with us. Our Motorola partnership is explicitly a non-exclusive contract. There would need to be another company wanting to work with us and capable of meeting our requirements for there to be another partnership though.
@Cambion @a53bdb Samsung is the best company when it comes to independence. Samsung produces their displays, batteries, cameras, and processors in South Korea mainly. If the goal is to minimize dependency on China and the US while still obtaining high-quality products, Samsung is the clear leader in that field. However, they are likely so large that they wouldn't be interested in a partnership.
@NewDay14 @a53bdb Many off the important parts are still made in China before it's shipped to other places the phones are made. There is no going around that. Beside, Vietnam is not much different when it comes to this...
@a53bdb To be fair, all phones are made there so that risk always exists anyway.
As long as GrapheneOS doesn't slack on their requirements including (but not limited to) being able to access low level stuff it shouldn't be much worse if you flash the phone yourself. And those kind of requirements are why Pixels where the only ones supported to begin with...
Will the 'ready for' (desktop mode) function work? This is a Motorola feature that I wouldn't want to lose after flashing the ROM. I once bought a Motorola specifically for this function.
@joonq @a53bdb Sorry, but despite US offices and staff, the company is 100% Chinese.
Here is why: -> Acquisition: Bought Motorola from Google in 2014 for $2.91B. -> Headquarters: Global HQ is in Beijing. -> Shareholders: Parent company Legend Holdings is Chinese. -> Leadership: CEO Yang Yuanqing is Chinese. -> Origins: Born from a state-owned research institute.
What might be cause for concern is if the ‘blond’ driving the world crazy were to target Motorola or Lenovo, causing them to pull out of the US market, or if, like Huawei, they were to have Android stripped away from them. At that point, they might decide on one of two things: either ‘steal’ the GrapheneOS technology, or strengthen their partnership with Graphene and make Graphene the primary software for Motorola/Lenovo. It could be an interesting development, but I imagine it would be stressful for the creators of Graphene
@FynnND Both iPhones and Pixels have official battery replacement kits available along with it being relatively straightforward for the most recent generations of each. You can already use GrapheneOS on a Pixel today.
Fairphones lack crucial standard privacy and security patches/protections. They're incredibly far from meeting our requirements. Fairphones aren't a serious option if you care about privacy and lack basic safety due to lack of kernel updates, etc.
thoughts on what Motorola was doing with the affiliate link injection or their TOS saying you can’t sell a phone you bought if you unlock the boot-loader and install a different OS?
This entry was edited (Thursday, May 28, 2026, 6:36 PM)
@top It wasn't authorized by them and appears to have been a supply chain attack from a company doing contracting work for them. It was quickly disabled via some kind of update
GrapheneOS won't be using any of their apps and services. GrapheneOS also won't be using their regular vendor code and vendor SELinux policy but rather a more stripped down version close to the standard Qualcomm SDK with the extra drivers, etc. needed on top of that added. It will have less nonsense than with Pixels.
Saw someone driving on lake Erie today. The lake still might be frozen, but with the warm spell we had the grass on the shore is partially visible. It certainly takes bravery that I don't be have to be zipping around the lake on a snowmobile in this weather.
A very long blog post about the various "safety and privacy" features that got added over the years to ActivityPub and how useless they can be in the eyes of users unaware of the inner workings.
There's nothing really new I talk about, but it is a long explanation of my reasoning behind why I don't take "features" such as signed fetches and interaction consent seriously. What can be considered "new" to most, is the last section of bypassing signed fetch enforcement without impersonation, which I talked about probably twice over the years.
Great post, thanks. I'm in the process of drafting a FEP for GTS interaction policies (collaborating with the team, since they said they weren't going to submit one), so the criticism is useful.
I can't say it's shifted my thinking on the feature much, but then I am in the technical weeds. I think of interaction policies as a way to declare & federate filters, so benevolent and willing servers can play along with them.
This is my current draft for the FEP summary, does it sound sensible?
> For example differentiating between Public and Unlisted is simply done based on where the as:Public special URI is. If it is in cc, the post can be considered Public, and if it is in to, it can be considered Unlisted
this is backwards -- to:Public = "public", cc:Public = "unlisted"
> If cc is empty and to has the Actor's followers Collection and the Actors mentioned in the post, the post can be considered Locked.
generally it doesn't matter if to/cc is used for the followers collection. what actually matters is that to/cc does not contain Public
> And lastly if cc is empty and to only lists Actors mentioned in the post without the followers Collection, the post can be considered a DM.
again to/cc doesn't matter here, a "direct" post is simply one where every audience member can be mapped to an account instead of a collection or unknown
Originally, I was drafting this in September, planning on dedicating it to Windows 10 Home becoming EOL. I also figured I’d share a meme that contained …
Nice, I have a similar laptop! Two things I learned, installing #Linux on my old Chromebook: With only 2GB of RAM, configuring Zram can be a gamechanger. And with 16 GB disk, btrfs with compression is very helpfull, since you can get 4-5 GB extra diskspace.
Without zram I had problems, when browsing with #Firefox (four tabs open). I figured that running out of RAM was the cause for freezing, on my 2GB system. After configuring #Zram the problem was gone. 👍
We made so many improvements with #HolosSocial, an ActivityPub server running on your phone. Big thanks to our beta testers who help us identify issues and suggest enhancements.
For tech folks: imagine pointing your domain with a CNAME to a relay and having your own ActivityPub identity with keys and data on your phone. The relay becomes just infrastructure, and you're free to move to another relay whenever you want.
I guess it needs the phone to be reachable from the outside via at least one IPv6 and better also at least one old IPv4 address and have it's battery-expensive radio never sleeping.
This entry was edited (Friday, January 23, 2026, 10:01 PM)
No, the relay handles that! The app works like any other, it syncs when you come back online and uses no battery when idle. The relay provides your stable identity and keeps your profile visible 24/7. Your phone doesn't need to be reachable at all. @HolosSocial
Holos announced they're working on adding custom domain support to their server. It's a really cool development, and I figured I'd share it here real quick.
If you're unfamiliar with Holos, it's an Activity Pub server that aims to be more relay like (somewhere between AT/Nostr and a standard Activity Pub account). The server acts as a relay, keeping a public copy of your posts and profile data online, but it delegates most operations to your client.
When I wrote about it a month ago it sounded like it was a possible consideration, but having it confirmed as something that's actually going to be the case is really cool to see. At the cost
... Show more...
Holos announced they're working on adding custom domain support to their server. It's a really cool development, and I figured I'd share it here real quick.
If you're unfamiliar with Holos, it's an Activity Pub server that aims to be more relay like (somewhere between AT/Nostr and a standard Activity Pub account). The server acts as a relay, keeping a public copy of your posts and profile data online, but it delegates most operations to your client.
When I wrote about it a month ago it sounded like it was a possible consideration, but having it confirmed as something that's actually going to be the case is really cool to see. At the cost of being a bit more technical, the idea of owning your identity on Activity Pub is really cool (you 'own' your own domain, plus are able to migrate even if the server is down since your client can make outgoing connections).
Anyway, figured it was worth a share, I'm looking forward to seeing Holos continue to be developed.
I'm experimenting with what I've deemed a 'mini blog' – smaller posts and different mediums separate from normal posts, while experimenting with different platforms/protocols, all linked together via a page and RSS link. If you want to see more you can follow here.
Custom domain support for #Holos is in development and coming along nicely! Use @user@your-domain.com instead of @user@holos.social, just point your DNS to a relay (changeable anytime). Actor URIs and post URIs stay stable forever, so switching relays requires no migration. Your RSA keys + domain = portable identity. Optional feature for users wanting relay independence.
Custom domain support for #Holos is in development and coming along nicely! Use @user@your-domain.com instead of @user@holos.social, just point your DNS to a relay (changeable anytime). Actor URIs and post URIs stay stable forever, so switching relays requires no migration. Your RSA keys + domain = portable identity. Optional feature for users wanting relay independence.
better yet: enable holos over tor. A tor address is a custom domain which you can actually own. Unlike a regular web address which you can only rent and is subject to potentially LE taking over, a tor address is yours forever once you register it. Holos over tor where I can register my own tor domain would be actually the Mastodon dream: truly descentralized
Every day, #Holos proves you can run your own ActivityPub server on your phone. We approached the problem differently: instead of copying existing platforms, you're in control. No imposed style - not Twitter-like, Instagram-like, or YouTube-like. Enjoy everything the Fediverse offers and contribute your way.
"Kirill Ilin's construction company Amcrete constructed the concrete walls of their ground-breaking new four-bedroom prototype 'layer by layer by layer' right on its Waiuku site.
He says houses made with concrete poured by a computer-controlled 3D printer are energy-efficient, quick to construct, and, because of their durability and recyclability, also sustainable."
"Every Activity Pub server duplicates content. Without it there'd be no seeing posts from anybody on servers other than their home server. It's literally the thing that makes the protocol work. If being on a protocol that specifically is designed to duplicate content isn't permission enough to duplicate content then the Fediverse goes poof. Zilch. Zero. Nada."
So a thing happened and I'm kinda flabbergasted. There appears to be a campaign to shut down the Mostr (Nostr <> ActivityPub bridge). Dunno how big it is, but apparently at least one DMCA complaint has been filed.
without knowing the specific dmca i remember people getting takedowns for files they didn't even host before. someone just sees it and files the papers and doesn't bother to check who it is.
ipfs gateways have a similar thing where they have to just block random CIDRs because
This was the DMCA prompted my mini crash out. There was something of a campaign to get bridges taken down, and the DMCA referenced standard federation. It was seperate from the 'yeet a bunch of automated DMCA alerts to random gateways' (lol, which could also probably get me going on a rant, but just a different rant about different things).
Yes and no. From a legal or technical standpoint, all this is true. It is legally allowed, technically necessary. But this doesn't mean it's ethical and that it doesn't violate consent.
I can walk up to two people speaking in "public" to eavesdrop on their conversation. But just because I can, doesn't mean it's right. I can scrape endless pfp images from WhatsApp through their contacts API. But doesn't mean it's right.
So no, just because it's possible it doesn't mean "permission enough". It' just means that it's necessary and people have accepted the risk. Explicit permission is something different entirely. This is about consent, a human property, not about technological or legal constructs.
Bridges are a bit different than scraping content or listening into a conversation. A bridge that bridges Activity Pub to AT/Nostr acts like any other ActivityPub instance, requesting a copy of the bridged user's profile in the same way another ActivityPub native server would. Same with Friendica (that I'm using right now to reply), it requested a copy of your post over Activity Pub, despite being native to DFRN (although, unlike Bridgy Fed/Mostr, Freindica bridges internally via plugin instead of using a dedicated standalone bridge). I'd argue that using a protocol designed for federation, on a server that defaults to federating with any instance not proactively blocked, is rather explicit permission to federate.
However, since it's just federating normally, it's easy to stop. If you block the bridges (at the user level or instance wide) they won't federate, just like any other Activity Pub instance. While I think bridges are important for the ecosystem, the beauty of something that's not centralized is that you can choose exactly what you do and don't want to interact with.
Absolutely, there's this difference. But I'd argue it can only be consensual if whatever happens is somewhat "expected". And depending on the service in question, this isn't always the case. Some people go to the Fedi because they don't want to have their stuff on AT...
@ljrk > I can walk up to two people speaking in "public" to eavesdrop on their conversation
That's not a valid metaphor for Public posts on a federated network. It's more like 2 people speaking on a stage using microphones, connected to a global livestream.
If you don't want strangers to listen to your conversation, that's easy! Just get off the stage. If you want to have a private conversation in a public space that people won't eavesdrop on, that's what Direct posts are for.
@ljrk > it can only be consensual if whatever happens is somewhat "expected"
That's like saying that striking up a conversation with someone at a speed dating event isn't consensual, if that person didn't expect to be spoken to at the event. If people choose to go into a situation, not expecting things that can be reasonably expected, that's on them. Not on everyone else for not being mindreaders.
But none of that will help if people refuse to learn about the options available and how to use them. Or insist that everyone else magically know what they intended, even if their app usage choices suggest the opposite.
Coda: If I stand in the street wearing a "free hugs" sign, it's reasonable for people to expect a free hug. Say someone hugs me, and I claim it was non-consensual because I only expected my friends to take up the offer made on the "free hugs" sign. Is that reasonable on my part?
When you post something as "Public" (instead of "Followers only", or "Private mention", to use the current Mastodon app terms), that's like the "free hugs" sign. People can reasonably expect to take that literally.
This entry was edited (Tuesday, December 16, 2025, 2:00 AM)
> unlike Bridgy Fed/Mostr, Freindica bridges internally via plugin instead of using a dedicated standalone bridge
At the risk of splitting hairs, I think you're stretching the definition of "bridge" beyond breaking point there.
A bridge connects any instance to any instance (of whatever it is they bridge). An AP plugin adds native federation to a single instance, allowing it to connect directly with any remote service federating over AP. Two quite different things.
Unless I'm misunderstanding something (fairly likely), theoretically, bridges could do the exact same, right?
Bob (Mastodon.Social) wants to see content from Alice (Tchncs.de). Mastodon.social dereferences a copy of Alice's profile/post & the replies/likes to said posts, creates a local copy that it serves to Bob, then deletes the local copy until another request is made.
Bob (Mostr Bridge) wants to see content from Alice (Tchncs.de). The Mostr bridge dereferences a copy of Alice's profile/post & the replies/likes to said posts, creates a local copy that it serves to Bob, then deletes the local copy until another request is made.
Even if an Activity Pub instance doesn't cache remote content long term (be it a standard instance or a bridge using the protocol), it's still gotta duplicate content to serve it to other users.
@eyeinthesky > they could also just dereference the remote URIs when remote content is accessed
They could. But arguably they're still duplicating content. They're just doing it every time someone wants to get the same post or profile through the bridge. So from a user POV nothing is different, it just increases resource consumption for the bridge *and* the origin server.
![Summary
Consent-based interaction controls are a way to declare, on a per-object basis, which types of interactions will be acknowledged by the object (or its owner) and who may perform them. For example, the author of a social media post might want to restrict the list of approved replies to a limited audience.
In a distributed system like the [ActivityPub] network, it is not generally possible to prevent people from publishing something that purports to interact with some existing object. However, the owner of an object may wish to limit the impact of the side effects of undesired interactions by applying filter criteria, and to make it transparent for third-party observers which interactions have been endorsed and which have been blocked.
To that end, this proposal describes a vocabulary to declare ahead of time how incoming interactions with an object are expected to be acknowledged, how actors may request to perform a specific interaction, how such a permission is granted or revoked, and how external parties can verify whether an interaction was accepted. This specification includes vocabulary to describe interaction controls for `Like` and `Announce` activities as well as for replies, but the interaction policy schema can be extended to novel interaction types.](https://social.trom.tf/photo/preview/640/41274401 "Summary
Consent-based interaction controls are a way to declare, on a per-object basis, which types of interactions will be acknowledged by the object (or its owner) and who may perform them. For example, the author of a social media post might want to restrict the list of approved replies to a limited audience.
In a distributed system like the [ActivityPub] network, it is not generally possible to prevent people from publishing something that purports to interact with some existing object. However, the owner of an object may wish to limit the impact of the side effects of undesired interactions by applying filter criteria, and to make it transparent for third-party observers which interactions have been endorsed and which have been blocked.
To that end, this proposal describes a vocabulary to declare ahead of time how incoming interactions with an object are expected to be acknowledged, how actors may request to perform a specific interaction, how such a permission is granted or revoked, and how external parties can verify whether an interaction was accepted. This specification includes vocabulary to describe interaction controls for `Like` and `Announce` activities as well as for replies, but the interaction policy schema can be extended to novel interaction types.")
i have a feeling that wouldn't hold up in court but i'm not a lawyer and judges are professional morons
silverpill
in reply to Nate • • •@nate
It didn't stall. Streams and its successor Forte support ActivityPub-native nomadic identities.
There are other implementers too: codeberg.org/ap-next/ap-next/s…
cc @nate
ap-next/nomadpub.md at main
Codeberg.orgNate
in reply to silverpill • • •silverpill
in reply to Nate • • •Some aspects of it are still being developed, but overall I think it is a proven technology. Forte is a project from the same person who invented nomadic identity and built Streams, Hubzilla, Friendica etc.
Nomadic identity may never become a part of the official spec because ActivityPub was published in 2018 and haven't received any updates since then. However, ActivityPub now evolves through FEPs (Fediverse Enhancement Proposals), and nomadic identity specs are published as FEPs (for example, FEP-ef61).
forte
Codeberg.orgYBG pern likes this.
Nate
in reply to silverpill • • •