If someone is interested in this, I'd recommend starting with extending base directory support to groups rather than group-based WebDAV. The latter is considerably more complicated and can't really happen until after some major upcoming architectural changes in Zotero.

the base directory changes aren't going to be affected by the sync architecture update. You shouldn't spend time on anything that directly involves syncing until Zotero 4.1 has been rolled out as a beta.

The commit that added relative linked attachment file paths is here:
https://github.com/zotero/zotero/pull/51/files
but this is not a small feat, it will require some time familiarizing oneself with zotero code more generally.

It's not as much the business model as you think it is. Dan has said repeatedly that they would accept a patch to this extent (as they did for relative file paths for personal libraries, which similarly affects the business model; this did include, as all complex pull requests do, a pretty significant amount of core dev time for code review, as you can see when you follow my link above). I'd also guess that the total effect that this would have on storage subscriptions is pretty marginal.

It's just that someone has to do it and core devs are busy with plenty of things with higher priority, including the sync architecture change that Dan mentions. Many other features, entirely unrelated to Zotero's revenue stream, have also long awaited implementation.

Charging for open-source software (rather than services related to open source software) would be hard and creates incentives to fork Zotero that I think the Zotero team has every reason to want to avoid.

The implementation.

Zotero doesn't have anything to do with the directory structure of linked files. Zotfile can do some of that if you want to (though it doesn't currently work for groups, so someone would have to expand that if that functionality is wanted), but Zotero itself is entirely agnostic about this and I think that's how it should be, so that people can set this up any way they want. So, no, you shouldn't require any default folder structure for relative paths to work and I also don't see why that should be necessary. In the above example, if the base directory is just set to "storage" everything will work just fine.

One thing that I'm wondering about is whether it'll be necessary to have a separate base directory for each library. That's a giant mess GUI wise, but if you're, e.g., hosting your own files on Dropbox, but also want to share a group via a network drive that'd be necessary.

If you're talking about the structure of attached files in the Zotero storage directory, those are a separate topic and not related to the issue of relative file links at all.

sorry, but you need to familiarize yourself better with Zotero before this makes sense as a technical conversation. If you're talking about the Zotero storage folder, you're not talking about relative links and you're not talking about a base directory in Zotero terms. Those are the things that Dan and I are talking about and those would be the most promising avenues to look at for getting a version of file storage for groups at this point.

Playing around with the storage folder _may_ be possible (Dan would have to say which other purposes the flat folder structure serves - it certainly would affect sync), but it's not currently on the menu and it wouldn't help users, e.g., to put files onto a network drive unless you're playing around with symlinks and the like—which is possible, but probably not the general user experience Zotero is going for.

OK, "base directory" (which you called this in the thread title) means something specific, and as adamsmith says that's totally separate from the storage directory — that's why we were confused. All previous conversations about linked files in groups relate to the former, since linked files aren't stored within the storage directory at all. And also as adamsmith says, base directories are really the user-facing mechanism for this. A handful of users or their admins may play around with symlinks in the storage directory, but that wouldn't be something we'd recommend as a general solution.

Anyhow, library-specific subfolders for the storage folder are planned — it's just the way it is now because it predates group library functionality — but migration will be extremely tricky. We probably need to make 4.0 fall back to the new structure if it can't find a file in the old structure, and then make the next major version gradually migrate the files in the background and write new files to the new structure. But I don't think we can actually move directories currently, so we'll need to do this file by file even for HTML snapshots. And thanks to security software, disk access can fail at any time, so there will need to be all sorts of error handling.

But none of that has any bearing on group-specific base directories, which would be a totally separate mechanism and require the fairly complicated UI that adamsmith mentions (because yes, it would need to be configurable per library).

Sorry, but this discussion is a waste of everyone's time. You're not understanding the issues here and are still conflating two completely unrelated things. (The UI is for base directories and doesn't involve key-based filenames in any way, and a directory name prefix isn't useful for any sort of network-based sharing that I'm aware of and doesn't help with migration anyway and certainly wouldn't be an intermediate step.) If someone wants to work into either of these things, they can familiarize themselves with the existing code and functionality and submit a patch, but I can't discuss this further.