Yes, but it's not clear how Blasta uses these extensions for its purpose. If it is using PubSub, then you'd be putting pivotal weight on that extension's authorization model, since PubSub is designed primarily for publicly disseminated information (i.e. newsletters and the like) and locking that down to just the author is definitely not intended use.All the technicalities are specified at XEP-0060 and XEP-0163
I'm not familiar with any of those.I did not think of it yet. I suppose the same considerations for Libervia, Movim and Blasta.
Keep in mind that this would be dealing with people's private data: browser sessions, history, browsing data, potential passwords, etc. Security considerations should be absolutely at the forefront of this, not an afterthought.
Data is stored on XMPP account storage.
XEP-0163: Personal Eventing Protocol
https://xmpp.org/extensions/xep-0163.html
Account storage (i.e. PEP) -> Node Name -> [Item ID, Item ID, Item ID, etc.]
schimon@palemoon.org -> Tabs -> [Tab 1, Tab 2, Tab 3, etc.]
schimon@palemoon.org -> History -> [Link 1, Link 2, Link 3, etc.]
schimon@palemoon.org -> Bookmarks -> [Bookmark 1, Bookmark 2, Bookmark 3, etc.]
Unacceptable.There is no storage encryption yet. I do not know whether it is necessary
Nobody but the end user should be able to access the stored data. Encryption is required, and encryption should be set up in such a way that nobody aside from the end user (not even the server admin) has access to this data. Storing everything in plaintext in an XMPP service instance is ridiculous.
It's been proven to be reliable as a messaging protocol, yes. But the issue here is not the protocol itself, but what is being built on top of it. As far as I can see, that is problematic here, as important things have not been given attention (or even thought). Yes, it's theoretically possible to make a single-user publishing node that can only be accessed by that user -- at significant server overhead. Building on top of that that a publisher is also a subscriber and not having a clear way described how this will be dealing with conflicts, e.g. 2 browser instances having updated data to push, etc. is a lot more complex which I don't see documented anywhere. As mentioned before the proposed server storage isn't secure. Additionally, leaving up in the air who exactly is supposed to be running these XMPP server instances doesn't give me any reason to think this was thought through at all. You expect us/me to spin up a public XMPP instance for storage in an insecure manner while I'm already running a Pale Moon Sync (weave) server out-of-pocket for Pale Moon?...XMPP has been proven to be reliable.
