Webber's trashed it (the initial author) and is working on a way to mitigate the problems of it by implementing incompatible changes, the biggest piece of software claiming to implement it doesn't even implement it (Mastodon), the only piece of software that stays semi-faithful is full of devs who hate it (Pleroma).
AP is completely broken for anything but publicly-scoped content, relying on a lot of trust for every party involved. This gets broken frequently, and has had consequences so far on networks implementing it (like half of them are incompatible implementations, so I think it's completely fine to say "networks").
So let's assume you can get Twitter to implement ActivityPub perfectly to-spec. Great! It doesn't work with literally any pre-existing ActivityPub software, and users' DMs and are more or less public, with users' private accounts literally being public.
I use AP daily, and while it's fine for technical users with a reasonable understanding that anything they post is public, putting naive users' data at risk has never and will never be acceptable; pushing AP will harm everyone.
> Webber's trashed it (the initial author) and is working on a way to mitigate the problems of it by implementing incompatible changes,
This is not true on multiple levels
Webber has not trashed ActivtiyPub. I'd love if you could provide some evidence.
And the updates, in the form of OcapPub, are not at all incompatible with the current AP. They're an optional add-on that has a good default behavior.
Source: I worked on the same paper where Webber talks about improving ActivityPub, I presented my own white paper about ActivityPub. I gave a talk about these possible upgrades at the ActivityPub conference and I do a podcast with Webber where we talk about ActivityPub.
Sure, Mastodon doesn't implement the full ActivityPub spec [0]. They're still very much behind the effort though, it seems [1] (or at least they were in 2018).
I'm not a Mastodon developer, nor have I developed with it, but surely there are learnings there that could potentially be contributed back to the W3C to make ActivityPub better (including making it more rigorously spec'd).
The people at the W3C are not gods - they're human beings just like the rest of us. Why not get involved in the conversation there?
The only genuine reason I can think of to split away from the ActivityPub effort to build a completely different protocol would be if the W3C's working group on ActivityPub is filled with such toxic politics that it's impossible to make any progress on making the spec better. (That's been the only reason I could see in the past when I've been part of protocol standardization efforts).
Without evidence of that, however, I'd say that it's far better for the community to get involved in making the existing spec better. Robust debate (supported by evidence, such as that which Mastodon's built up) is incredibly valuable to the community as a whole.
Also, it's incredibly valuable from a political decentralization perspective to have as neutral a party as possible facilitating the standardization efforts, to minimize the risk of Big Tech shaping standards in ways that would suit them financially (and potentially against the interests of the average internet user).
Sure, Mastodon doesn't implement the full ActivityPub spec [0]. They're still very much behind the effort though, it seems [1] (or at least they were in 2018).
Not only this, but they go against it in multiple places. How they've implemented 'summary' and the bizarre things they've done to create compatibility with Misskey (but not in an actually-compatible way, Misskey's had to patch their own solution every time) has made every implementation have to implement an against-spec trashfire.
I'm not a Mastodon developer, nor have I developed with it, but surely there are learnings there that could potentially be contributed back to the W3C to make ActivityPub better (including making it more rigorously spec'd).
Alternatively, the AP spec is fundamentally broken in many ways, and that effort would be better off going into a protocol like Secure Scuttlebutt (not a fan, but it's much better than AP) or Diaspora (also not a fan, but it's much better than AP).
The people at the W3C are not gods - they're human beings just like the rest of us. Why not get involved in the conversation there?
The only genuine reason I can think of to split away from the ActivityPub effort to build a completely different protocol would be if the W3C's working group on ActivityPub is filled with such toxic politics that it's impossible to make any progress on making the spec better. (That's been the only reason I could see in the past when I've been part of protocol standardization efforts).
Not only politics, but it's incredibly slow. Webber has written a post on how troublesome the standardization process was, though he doesn't go into just how bad it was:
Without evidence of that, however, I'd say that it's far better for the community to get involved in making the existing spec better. Robust debate (supported by evidence, such as that which Mastodon's built up) is incredibly valuable to the community as a whole.
There are already existing specifications, none of them as bad as ActivityPub. I'm fully for going in one of those directions, but AP is more or less a failed experiment.
Also, it's incredibly valuable from a political decentralization perspective to have as neutral a party as possible facilitating the standardization efforts, to minimize the risk of Big Tech shaping standards in ways that would suit them financially (and potentially against the interests of the average internet user).
W3C is not neutral, and not only are they not neutral, but the RIAA and MPAA are people with enough sway to have messed up the entire web multiple times (see: making EME a standard).
A neutral party sounds great! The W3C should not get to be involved, however.
Hi, Chris Webber here. You're quoting my blogposts out of context.
Yes, the standardization process was a difficult one. Standards efforts often are, and social web ones especially. Nonetheless I think we did a good job.
The purpose of those posts is to ask people to stop fighting each other and try to work together; it feels highly ironic for you to quote them to increase division.
> W3C is not neutral, and not only are they not neutral, but the RIAA and MPAA are people with enough sway to have messed up the entire web multiple times (see: making EME a standard).
> A neutral party sounds great! The W3C should not get to be involved, however.
Perhaps I got lost along the way, but... we're still talking about Twitter here right?
Are you seriously calling out the W3C, an open but obviously flawed organisation, for finally capitulating on DRM, after huge public drama and well-documented opposition from within the W3C. DRM is something entities such as Twitter use as a matter of course; there is no public discourse, nor documentation.
This isn't even as basic as pots calling kettles black, any reservations one could have about W3C as an org are positively laughable when the alternative is a standard stewarded by a corporation with the size and influence of Twitter.
> Twitter making a standard would at least result in something not stupidly broken.
Agree with most of your comment, but I can't see where this is coming from. I would be shocked if any "standard" coming from Twitter would be anything but broken.
Again, you're saying W3C doesn't work in the interests of the user, but ignoring that Twitter works actively against the interest of the user.
W3C isn't ideal, but the alternative being discussed is devoid of any merit whatsoever.
The alternative being discussed is Twitter appointing a different neutral party: if they're bending to the W3C, they're already appointing a "neutral party" to do the work for them, the only difference is changing who they trust from another giant organization that's very clearly apathetic about user interests to one that does: the SSBC would be perfect, for example.
> Secure Scuttlebutt (not a fan, but it's much better than AP)
If you have any specific feedback about which improvements are most important to you, I'd love to hear it. It's hard to see things with fresh eyes after you've been working on them for a bit.
I actually think that the SSBC has done a fantastic job with it: the work that's been done is really impressive. I'm mostly just not a fan of the ground it's built on; the implementation itself is amazing, and the protocol is solid. I wish you good luck with it!
And to anyone unfamiliar, I recommend checking out the "Principles" section of the handbook; there's a lot of interesting stuff in it, and it proves that Scuttlebutt's really got the best culture/morality of any distributed network so far:
It's a quirk of the main feed encoding type, but there are other feed types (e.g. Gabby-Grove) that are major improvements. Right now the main hurdle is just adding support for more feed types to the major clients, which is something I'm actively working on.
SSB is great; I'm not sure if others would agree, but while I think it has a lot of problems, none seem inherent (i.e. while they mightn't necessarily be easy to fix, they wouldn't involve any major architectural overhauls or scratch rethinks; what's there is conceptually sound).
The main issue for me is performance and resource usage, which is tricky since a lot of the traditional solutions to perf/resource challenges are cloud-based, which would erode ssb's value. Thinking about SSB on older recycled or embedded systems, etc. is hard.
The other is NIH; this is definitely something I feel the community is acutely aware of however; I recall seeing discussions of parallel implementations in Kafka, etc. years ago. I haven't kept up with recent development though.
The performance problem is hard, but we have lots of active experiments that I'm optimistic about. Implementations in Golang and Rust, a handful of great database experiments (even simple stuff like Sqlite), and a bunch of people who are actively using SSB on low-resource devices daily. The Manyverse app in particular runs on Android devices, which are going to be very resource-constrained when compared to most computers.
The NIH problem is hard, but I think we're moving in the right direction.
I think this is a mischaracterization. I've read Webber's writing on OcapPub[0], and his more recent writing on ActivityPub[1]. I'm not getting the impression that Webber thinks ActivityPub is broken, or that he's stopped advocating for it, or that he's trying to replace it.
In his own words:
> "OcapPub" sounds like a new protocol, whereas it's really just a way-to-use ActivityPub mostly as it already exists. Maybe time for a new name for that?
Even if Webber does think ActivityPub has fundamental problems, he doesn't seem to be discouraging anyone from pushing it. I mean, go ahead and watch his most recent talk and decide whether or not Webber is "trashing" ActivityPub.[2]
> "It was 3 years of really hard work, and it wasn't clear in the process if it was going to pay off. And it has. We now have this as a standard that we can all use to be able to speak to each other, and I think this is really exciting."
> putting naive users' data at risk has never and will never be acceptable
That's a misrepresentation of history. Being responsible for your own data hygiene has been the norm in many online circles for a long time. I have often experienced pretend-stalking (e.g. via exif information not stripped from images) as a way of opening the eyes of community members about the data they leak.
Thank you for saying this. ActivityPub is so wrong in so many ways, and still people keep pushing it as if it was a silver bullet. I think people who talk about it and think it's very good never tried to understand it or write something with it.
I don't think people are pushing ActivityPub as a silver bullet, so much as they're using it as "the currently-available and less-awful alternative to closed silos". If someone is starving, they're not going to hold out for a gourmet cheesecake that's a year away from being made. They'll happily take an immediately-available baked potato instead.
People are pushing AP as a silver bullet. Look at this thread! Twitter is funding work to be done in more than an year and people are saying that should just use AP.
I disagree. I think most of the people in this thread are promoting Activitypub merely as a starting point. Sure, it could use some tweaks and improvements, but it's a good foundation to build on.
Your previous comment came closer to the truth: ActivityPub may work today _as a workaround_, a half-baked alternative to closed silos; but it doesn't have a solid foundation, its problems can't be solved by tweaks and improvements, and that's what every of its critics say.
I think this is going to be an "agree to disagree" situation. Frankly, I think Activitypub is just fine as the basis for building Twitter alternatives. Most complaints I've read about it are from people who dislike its lack of privacy and of the necessity of trusting servers with regards to private messages. I think those people are trying to fit a square peg in a round hole.
I'm actually building an Activitypub implementation myself. I quite like the protocol and the philosophy of "twitter without Twitter Inc.", but I'm thoroughly sick and tired of the rube goldberg "framework on top of framework on top of framework on top of obscure language for the backend" insanity that comes with the usual implementations. So I decided to do something about it. I'm working on an Activitypub server in Go, sqlite, and a pure vanilla javascript frontend. My goal is to have this be dead simple to install and maintain on a barebones VPS for anyone with a modicum of Linux commandline experience. One static binary, one small config file, one folder with a handful of javascript/css resources and html templates. And that's it. No bloody vue, react, angular, ember, or rails. And definitely no f---ing node.
(Breaking out this sentence into blocks because it's very large.)
The specification as-written is really, really bad (though I don't think this is a fault of the protocol),
Synapse is kind of...and work on Dendrite seems to have mostly stalled,
the billion people signed up on matrix.org has allowed for a sort of de facto centralization (not a huge problem, though in practice it sort of is, given how much the server buckles under the weight of all of the users; might be solved if it's ever moved onto a more performant implementation?),
the lack of encryption by default is iffy (though done for understandable reasons).
To lend credence to the specification being bad:
"I tried writing a matrix homeserver but I couldn't figure out how the state resolution process works" said by the author of Audacious/one of the authors of Pleroma/much more, so certainly a person who should be able to understand something that simple:
I know multiple people who've tried to implement the spec but who have gotten stuck on things that should be simple but are unclear if going by the spec.
> The specification as-written is really, really bad
We get a pretty wide range of feedback on the spec fwiw: some people seem to really like it. Others say that it’s “really, really bad” which doesn’t exactly give us much to go on...
> Synapse is kind of... and Dendrite is stalled
We have no choice but improve Synapse currently, and while it is still quite a resource hog it’s improved by at least 3-5x over the last year. Dendrite instead has become more of an R&D project for future homeserver shapes, but it’s not entirely stalled.
> The matrix.org server causes de-facto centralisation
The server has been less than 50% of the visible network for several years now - and ironically the datacenter perf issues (unrelated to Synapse) we had over the last few months have shifted that balance further - it’s about 35% and dropping. Ideally we will turn it off entirely once we have decentralised accounts.
> lack of e2ee by default is iffy
Our main project right now is to fix this. Cross-signing is mid flight; E2E search is done; Pantalaimon (E2E compat for dumb clients) is done; remaining key distribution bugs are in flight. We’re aiming to turn it in by default in Jan.
> “I couldn’t figure out how the state resolution works”
State resolution is the main technical novelty in Matrix, and yeah - it’s hard, much like git’s merge resolution is not exactly easy either. Unfortunately it comes with the territory; if you want to have consistent room state while replicating them over a byzantine network of servers to stop hijacks and other abuse, you have a relatively hard problem to solve. We got it wrong the first time; the current version gets it right (as far as we know).
It looks like you guys are on the right path for most things, and I wish you luck!
Why do you have no choice but improve Synapse?
One of the reasons you seem to only get negative opinions along the lines of "really, really bad" is because "The way it's written is stylistically bad/unapproachable and an entirely different approach should probably be taken" is something that takes a few hours to diffuse into something useful, and not something most people really receive in a way that's productive. It takes a lot more effort to give truly constructive, workable criticism than expressing any sort of opinion, negative or positive.
> It looks like you guys are on the right path for most things, and I wish you luck!
thanks :)
> Why do you have no choice but improve Synapse?
There are quite a lot of Synapses out there right now, and Synapse's featureset is pretty mature. Given we have pretty high profile people running Synapse (e.g. all of the French government) we have no choice but to invest the time to polish it and make it more efficient and stable. In an ideal world we'd have paused on Synapse ages ago and focused purely on a next-gen server, but we can't leave Synapse users in the lurch. Dendrite will be getting some attention in the coming months though, but not as a direct Synapse-replacement, but more of a playground for more experimental stuff.
> It takes a lot more effort to give truly constructive, workable criticism than expressing any sort of opinion, negative or positive.
True. fwiw, my guess is that kaniini was trying to implement state resolution before we published the first stable Server-Server API back in Feb - where it most certainly was the weakest part of the spec (and had design flaws too, which is why we hadn't bothered speccing it in detail).
Others have better responses to the rest of these points; many of them are still significant issues though a lot has progressed over the last couple years. I can preempt one though by saying alternatives to Synapse like https://github.com/matrix-construct/construct are probably something more aligned with your interests. (disclosure: I started the project with kaniini).
After more than two years in and around this space I'm still comfortable with stating that I'd take Matrix with all^wmost its flaws over ActivityPub. All of these protocols kind of suck. I see Matrix as having the lowest hamming distance between where it is and where it should be.
> I'd take Matrix with all^wmost its flaws over ActivityPub
protocol-wise, which flaws are currently the most egregious from your pov? (i.e. `all - most = ?`) (And if any are security issues, please chuck them to security@)
I'll just pick one. Matrix is resource-heavy, even in the best of times. There is a confluence of smaller contributing factors, and several effects on both its usability and developer/platform friendliness. Consider this anecdote of the overhead of sending the message "hi" as a baseline: in Matrix, this takes about 1KiB on average after all is said and done in JSON (and varies, unfavorably). So to over-simplify, that's 1K to the disk, 1K to each server in the chatroom, for which there could be several hundred, and 1K read on query from clients and other servers -- all for a 2 byte payload.
Before I'm accused of being unfair because there's always going to be a ridiculous ratio for something like a "hi" message, consider some alternatives for both the format and payloads of the fundamental protocol primitives. Most of the messages contain cryptographic metadata which has a succinct binary representation, but JSON requires base64; when represented naturally with CBOR the overhead can be reduced ~40%, and without encoding/decoding either. Consider that virtually all of the overhead in "hi" is either cryptographic hashes or signatures or integers (depth/ts) which would benefit from compact formats.
Does representation actually matter though? Why can't I just store Matrix in my format and federate with your format? I guess this is an example of where theory and reality collide. One cannot write a server which handles messages as abstractly as possible (leveraging these JSON/CBOR extensible formats) while at the same time knowing which fields have a more efficient binary representation and transforming that. In reality that just looks like a CBOR message with a bunch of base64 plaintext strings. It doesn't achieve that 40%.
All of this is important because of Matrix's (superior) design over its event abstraction. When the whole protocol is hinged on fundamental primitives (a good thing) attention to detail and focus must be given to those primitives. The more optimized they are, the more everything built with them is also optimized. When the foundation is efficient, developers can do more with matrix and enrich the user experience. For another example, matrix has been reluctant to give developers the power to store shared-program (i.e bot) state efficiently in a chat room. This is because there's no mechanism to delete state_keys, or even discard overwritten state itself. That's an important cornerstone that's missing while the rest of the tower is being piled on.
It might be possible to confuse any of these issues as trivialities, and their solutions as bike-shedding. I contest their importance is evident in how they emerge to shape the character of the entire system. Consider: does matrix require the entire DAG to be acquired like a bitcoin block-chain? Then I better be careful and conservative about messages. Does matrix allow gaps in the DAG and have a smaller chain for auth? Then I can be liberal about messages and delete stuff later. When I go to build an application which communicates over Matrix those qualities emerge as fundamental limitations or liberations of what users can experience.
So i think the summary is that the SS API needs to support alternative encodings (and thus signings) than JSON. Totally agreed; as you know we've already been experimenting with compact representations including CBOR (https://matrix.org/blog/2019/03/12/breaking-the-100-bps-barr... etc) which applied both to CS & SS API, which took the ratio down massively. However, we fudged it there by disabling the hashes entirely (given it was on a trusted private network). So from my pov Matrix is not remotely tied to the crappy HTTPS+JSON transport for S2S API in the long term, and it's only a matter of time before someone concretely proposes something better.
I selected some examples because I don't want to be lost in abstraction, but please, I am asking kindly that you not focus on my examples (unless it's pressing) because the issue here is systemic. I'm not giving these examples for you to just retreat back with your head down and address them. The locus is more fundamental: the etiology for why these errors even exist and why there continue to be new ones all the time; all at great cost, perhaps even existential cost. You should be concerned with that bigger picture, surely.
Scores of other issues could have been cited, but I included the representation example having confidence you'd probably tout those exact experiments and respond with that blog post. Your conclusion at the time was that CBOR and JSON had negligible differences. The company then proceeded to de-prioritize any serious work in that direction while simultaneously ramping up efforts for end-to-end encryption by default. This was a flawed conclusion and it has demonstrably added to your tower of debt. Even my "hi" example is already passé because now that too is another giant base64 string adding to this jumble. You can't bolt Ferrari body panels on a Honda and call it a Ferrari.
I can spend all day citing issues just as poignant, and you might even be kind enough to elevate them against the ~10,000 other [github] issues they're contending with. I can spend all day unpacking the string of missteps leading to all of your engineering disasters. It's not going to have any returns- not for either of us. It doesn't root the problems.
If I could impress upon you some serious advice, it would be to value people less transactionally. Don't estimate a person's worth by how they fill a few open gaps in your grand master plan and then dispense with them as if they won't be filling in any more. Avoid that by valuing people by how they think, and then don't try to think like them yourself. Delegate to them instead.
i think the tl;dr here is that we have a bunch of tech debt, and we’re not working on the things that you think we should be working on, and that we undervalue your input and should delegate to you rather than discussing specifics.
i’m afraid that nobody is going to delegate to you, but you are welcome to contribute via concrete spec proposals, which are assessed based on merits (and whose review is far from dominated by me; if they were my own proposals might move along faster than they do). if the spec process is too slow and doesn’t work for you, then feel free to spell out the proposal however you like.
Who am I to submit a proposal to fix fundamental problems in your company? That's called consulting. You just raised an 8 million dollar Series A you are soliciting me to work for you for free, in the leaf comments of a Hacker News thread? Are you for real?
I volunteered at least three solid examples of fundamental indecisions that have unambiguously cost your investors alone millions of dollars over several funding rounds; lest I mention also cost every poor soul that has volunteered their free time in the name of FOSS -- an ethically ambiguous embrace by you at best; every one of them is locked into the cost of your missteps.
I have clearly linked these indecisions to real-world outcomes. It's all history by now. The foundations of state resolution weren't in place when you built Communities/Groups so you didn't use the matrix chatroom; you built an entirely new inferior HTTP protocol without any state or replication whatsoever over several months. Now that you finally prioritized fixing that underlying problem with rooms there's a need to replace and spec an actual Groups system. In the meantime nobody can develop Matrix Groups into their software, not my server, not clients like Ditto, etc, because you tell everyone not to. You're going to overhaul the whole thing. You're doing them a favor by saving them that wasted effort. But Synapse and Riot use Groups and Matrix promotes it on matrix.org; still there's been no serious visible progress toward groups-as-rooms.
This is why Matrix is indeed a de facto centralized system. Let's not even get into issues in this system where every server trusts matrix.org for cryptographic keys. Matrix is really centralized around you.
In the end nobody is working with you. I have the only third-party implementation of this stack. Nobody is working with me either, but that's called the transitive property.
You have some time to think about this. I would say until the next recession hits. Then this is over. The way you do things won't survive that.
I've contribute to Mastodon and run an instance. Yes, it's very silly to think you can use Activity Pub for non-public things .. but isn't that going to be true of ANY distributed social networking protocol?
Direct point-to-point we can make secure (relatively) yes. You can run your own e-mail server, setup up PGP keys, and once you make it through that usability nightmare, you now have secure e-mail (if you trust your hosting provider) that will probably get dropped as SPAM 1/3 of the time when e-mailing anyone on Google/MS/Yahoo.
There's an interesting case where Mastodon and Pleroma respect and forward delete requests. Say you have a thread started on BigInstanceA and I reply from PersonalInstanceB. Someone from IAC replies to the same thread and B sees it, but A can't because C is banned from A. The reply gets dropped. You now have two conversations not in sync.
Say A deletes the original. B gets the delete request, but C never does, since it's a banned instance from A's perspective and doesn't exist ... even though it has a full copy of the deleted thread.
Deletes are truly fucking silly in the AP world. As much criticism as Zuckerberge gets (and deserves), back in the day he just wanted everything public, and I'm kinda for that too. If I post something online, it's never personal. If I need to talk about something personal, I call a friend, or text them, or meet them in a bar or plan my next vacation to be in their city. Real conversations don't happen in this space.
Not necessarily, if you use an actor-model where content is addressable using cryptographic keys, then you can get an object-capability system where having a reference to a piece of content is sufficient to grant access to it. This seems to be the way that some people are going with newer designs.
Also, the way you ban people is basically by having unique capabilities handed out to everyone. Then you can do various things to stop access (it's called a revoker in ocap jargon). See http://habitatchronicles.com/2017/05/what-are-capabilities/
Perhaps ActivityPub is struggling because it tries to be too much. If it does well at being Twitter, why must it also be Signal messenger? I don't use DM's much at Twitter, if that feature wasn't a part of AP/Mastodon, I wouldn't cry!
That comes across in delete requests. There's no way to guarantee that a server would honor that request. I don't think a blockchain style solution is needed -- just don't try to offer things that are impossible to offer. (There's this idea that AP/decentralized will be Nazi-free... what a ludicrous promise! Although, perhaps that's more an expectation of the users than the protocol authors...)
I would guess it's based on the fact that when most people hear "access control" they think of "access control lists", but it's possible to do decentralized access control. That's what ocaps are.
ActivityPub can be private in the same way email is private. All the people in the recipients chain will have a copy of the object you're sending. If in these recipients there's the Public namespace, then yes, you can't talk about "private" any more, but outside of that ActivityPub supports private interactions.
As a followup on this discussion, I actually spent half a day today to add private messaging to my ActivityPub service. It actually works.
Use search to find Kaniini's threads about Rapunzel.
Also, no, it's not something inherent in distributed social networking as a whole (previous attempts have avoided it), and it's not even inherent to push protocols, but without a bit of thinking behind it, it's easy to collide with.
Webber's trashed it (the initial author) and is working on a way to mitigate the problems of it by implementing incompatible changes, the biggest piece of software claiming to implement it doesn't even implement it (Mastodon), the only piece of software that stays semi-faithful is full of devs who hate it (Pleroma).
AP is completely broken for anything but publicly-scoped content, relying on a lot of trust for every party involved. This gets broken frequently, and has had consequences so far on networks implementing it (like half of them are incompatible implementations, so I think it's completely fine to say "networks").
The specification itself is far too ambiguous. Here's a post by a maintainer of Diaspora explaining this part further: https://schub.io/blog/2018/02/01/activitypub-one-protocol-to...
So let's assume you can get Twitter to implement ActivityPub perfectly to-spec. Great! It doesn't work with literally any pre-existing ActivityPub software, and users' DMs and are more or less public, with users' private accounts literally being public.
I use AP daily, and while it's fine for technical users with a reasonable understanding that anything they post is public, putting naive users' data at risk has never and will never be acceptable; pushing AP will harm everyone.