Bmd was designed with the "friends sharing bookmarks" problem in mind. Read the intro again. That means each user is given control over the content of his own instance of the databases he maintains. An info replication or mirroring mechanism (hostsurvey) will replicate new bookmarks from each friend's instance unless told otherwise by a rejection mechanism.
On the storage issue side, the Bmd Perl modules create a table abstraction layer over a bunch of flatfiles that mimics a traditional RDBMS. The records are stored in flatfiles that Jester and hostsurvey can treat as a unified database. The Bmd platform enables simple management of these files using an indexfile (something.bmd) as a centralized configuration file. Then, it's many functions provide a crude interface for changing and viewing the tables. Most of this flatfile database is crap, so I don't plan on keeping it. I'll have to switch to a real RDBMS later. What matters now is your bookmark collection is stored in a relational database format.
As I was saying before, the hostsurvey is the tool that "connects" each Bmd user on the internet by replicating each user's instance to the others. In theory, any new record entered by one person could eventually spread to everyone by this replication process. This theory assumes three things. First, everyone is using hostsurvey to monitor the changes of some other users in a fully connected network. Second, there aren't too many people trying to put a stop to this new record with the reject tables. And third, that little "Six Degrees of Separation" theory is correct :-). As long as your circle of friends somehow intersects with everyone else's, then there can be a hostsurvey-connected path among everyone. We'll probably have to create new circles of friends anyway with host community sites. I don't think we can trust "Six Degrees" to do the job alone. Especially when most people have never heard of Bmd.
Technically, the Bmd platform is just a few Perl modules in your /usr/bmd directory. Any program that needs to use them can just include them like a dynamic library with Perl's "use" command. There may be ways to do the same in other languages, but I don't know what they are. We can make other bindings later. Read the function docs for more information.
The indexfile serves as the config file for a database. It basically names the other files so Jester knows what they are called. Schemas go in schema files which are often named (something).sch . You can put all of them in one file, or several for a single database. Table records goes in table files which are often named (tablename).tbl . The records are stored in semicolon delimited lines. Several files may need to be concatenated to make up a single table. There is no need to keep it all in one file. Lastly, there are sync files which are named (something).sync-(some date) . Sync files are a means of communicating only a single day of changes to other people's hostsurveys. For a large database, nobody wants to download enormous table files to get one new record. Therefore any changes made to your database are reflected in that day's sync file. Finally, I recommend you store all files except the indexfile in a "member directory." This will help avoid the anoyance of file clutter. The member directory is specified in the indexfile, and it should be considered a default search path for all other files.
Anyway, Bmd is very decentralized in terms of storage and connectivity. New info spreads throughout the Bmdnet with the help of a semi-automatic mirroring scheme implemented in hostsurvey and Jester. There is no server yet, so you have to use a web site to share your flatfile database right now. Maybe we'll throw a server together later. Read hostsurvey design next. It'll help you understand how everyone is connected.