By "need to figure out what the strategy will be for users who use the same account on multiple computers" do you mean people should be able to use Firefox 2 at work (for example) and Firefox 3 at Home, or would it be okay if the FF3 version would require FF3 for all clients? (would make it lighter I guess ...)

I am not sure how the new bookmark system works, but it would be fun if we can access google bookmarks from there directly instead of passively synchronizing them when the window is closed. It is very inconvenient to keep 2 sets of bookmarks in one browser.

Is anyone picking this code up? Weave 0.2.0 is far from being GBS.

thanks for looking into the development of this everyone, it is greatly appreciated without question, weave becomes more frustrating with each update quite honestly, instead of building concrete functionality, they just keep on trying to add more.

please on this project just focus entirely on getting the same functionality that GBS offered in FF2 up and running on FF3.

The available code is for the client only. I'm assuming data hosting on Google would be discontinued by the end of 2008 as well, as it was mentioned in the blog.

Wouldn't there be code on the Google server-side needed for data transfer and handling?

I think Google will keep server side running if the Firefox3 support will work, otherwise the effort doesn't make sense.

@florian.idelberger: yes, I was concerned about mixing FF2 and FF3 clients. I suppose you could require support for FF3, and that would be easier.

I believe there is a possibility to get the server-side code working in python... then this could be hosted on Google App Engine. Thus, Google would still be hosting the server-side code without officially "supporting it".

I would love to be able to specify my own ftp/webdav server to sync to (ftp is simpler to setup), currently stuggling with weave on a PC with FF3, and using GBS on 2 PCS with FF2

https + webdav would be the way to go - you'd get versioning & a high security level thrown in

I would also like to see the ability to use my own server for the syncing.

@jambob You need to pay for over 500MB on Google App Engine. So this may be ok for an individual but not everyone. Specifying your own server seems to be the way to go.

For storage how about using a P2P data storage method? If you encrypted the data with a private key before sending it out into the network that would be fine. Gnutella or a torrent-style network could work. It'd be a clever way to manage user data.

Or you could have a list of federated storage servers that people could donate to?

Personally I'd love if this extension supported something like being able to upload to your own server via SFTP or SSH.. or maybe even writing it to Amazon S3

I agree with brandon. I use browsersync strictly because of its functionality, but I would much prefer to securely sync my data to my own server instead of uploading to google, amazon, et.al.

While putting it own one's own server would be preferable, those (the many) who do not have personally accessible servers would be at a severe disadvantage, and would cripple the functionality of this plugin for those people. Perhaps the ability for both?

But here is a question: Why would Google discontinue this plugin but still support servers for it (beyond 2008)? Also, why have they discontinued support to this plugin?

The answer is probably that it costs about a HUNDRED grand a year per programmer on a project, but only a couple grand if that to keep a server up.

If the project isn't likely to recoup costs (and make more than it costs per programmer time) there isn't much of a reason to keep it.