Allowing "multiple maintainers" should never happen. There has to be a limit. Even with a permission-based system, the list of allowed contributors would be arbitrary and we can assume it can grow to allow "everyone", which is a moot point.

For important/useful/popular PKGBUILDs one can set up an svn or git repo to allow those interested in that particular package to contribute.

Archweb supports multiple maintainers for official packages. I don't see the problem for these. Why shouldn't we allow a list of users?

You don't need a svn/git repo to have users contribute, they already do that via the comments anyways, but it still comes down to the maintainer to update the package. Besdies, this has already been implemented for arch repo maintainers. Plus there are other issues like maintainers abandoning maintainence without actually abandoning package ownership. And most FOSS stuff always has multiple maintainers.

Archweb is not open to everyone, unlike the AUR. Allowing any registered AUR user to click "join as a contributor" (or a derivative thereof) is a potential risk for good PKGBUILDs being maintained properly, assuming that immediately upon "joining" that user is able to upload (and thus replace) a PKGBUILD. It is not as trivial to "revert" changes like in a revision system.

I'm not against a permission-based implementation, actually. Just that I don't think it'll be trivial to implement :)

example:

User clicks "adopt package". If no maintainer, user is set as maintainer. If there is an existing maintainer, he is asked to share ownership. If he accepts, then the user is added as a maintainer. They'd all have equal rights, and a disown would remove the user from the list.

Yes, that one would be fine :)

That might open it up to hijacking, if the new maintainer can remove the previous maintainer. Better to let the current maintainer grant requests or have tiered rights.

Tiered rights would be a little harder to do, and I don't think it's needed. Maintainers could only remove themselves, not the other. TUs would handle removing someone else as they currently handle deletions. If you don't trust someone, don't accept the request. I think that would be fine. ACLs would be really overengineered for this I think. What rights could possibly be denied? The only real thing that being a maintainer lets you do it upload new builds and set category.

Now, it appears we're rushing probabilities. The existing maintainer will already be the one who decides whether to accept the request (I'm sure there will be some kind of communication between them). So in that case, we blame it on his/her wise decision, and then the offending contributor can be jacked for real :P

Sounds about right. We can never make it 100% bulletproof anyways.

Now, if only any of us knew how to actually code for this :P

What about basing AUR on GIT? (eg.: i have all my packages on github, so anyone can send me git-formated patch or pull request. btw: http://github.com/harvie/archlinux-packages )

And yes. At least patch and diff support would be cool.
Every package can have directory ./patches/ in it and users will be able to upload unlimited amount of patches (or even PKGBUILDS which will be processed using diff after upload) to it. There will be nice colorfull diffview and maintainer will be able to accept or reject the diff with single click. There can even be accept/reject links in notification mail, so we will be able to accept/reject the patch from mail using one single click on link.

Just maybe also add some daily cap for the amount of requests a single maintainer can receive (and maybe even some *Block* button for people who can't take the message). Also the unaccepted requests should expire at some point.

Then of course the other possibility would be for the 'main' maintainer himself to send requests to other people. If that could be combined with  FS#34692  in inactive cases, that'd be.. well awesome.

And for the fact that somebody might destroy other one's package there should be some sort of backup logic. It's not enough to just revert to what the package used to be after the main maintainer's last commit, since that might have been a _long_ time ago.

I see it's implanted with commit #fc23a9b (https://projects.archlinux.org/aur.git/commit/?id=b32458cb8a043422bfc2962c03a70deaee9eaca9).

But why not allow pull requests, or something like that ?

You can use git-send-email(1) or any GitHub-like service for pull requests. Git is a distributed VCS.