[Standards] Re: Proposed XMPP Extension: Pubsub Node Relationships

Is XEP-0248 really that poorly implemented in PubSub services? As I recall, it wasn't that hard to do. Also, while on the subject of this proposal's critique of its competitor (I do dislike these marketing screeds in XEPs), the matter of deletion and security model seems to suggest a misunderstanding of what Collections is and does. The deletion is because, amongst other things, a leaf node can belong to multiple collections, and so deleting a collection certainly should not delete its leaf nodes - sometimes. The security model is because notifications "bubble up", and was a simplification. To do otherwise would mean that the bubble-up needs to carry the originating node, and ultimately, if you have collections of collections, a list of nodes to check the access against. I think that's probably better, but it is more complex to develop and test. But it only affects the notifications and not more broad access. This specification, though, has some interesting limitations - a node can only be linked to one other, and that node in turn shows no indication of being a "linked node" - the implementation would have to track this though. I kind of hate to say it, but it you're going this route, I'd rather see a more generalized concept of "linking" using the RDF kind of approach, and a secondary concept of "subordination" to control deletion requirements. If you approach the problem in this way, then it starts to look like a complementary system to XEP-0248 that mostly addresses your concerns with it, rather than a replacement that's broken in its own way. Does that make sense? On Mon, 14 Oct 2024 at 17:21, Daniel Gultsch <daniel(a)gultsch.de> wrote: