Replace solid:inbox by ldp:inbox

[solid]

Replace solid:inbox by ldp:inbox

[kjetilk]

I feel the need to also point out:

Stay on topic. Remember others voices need to be heard as well as yours and you must allow the space for other members to participate (e.g.: don't monologue or respond to every comment.).

[kjetilk]

We have a bunch of rather different issues here. One is what should happen to the solid:inbox property in the vocabulary if we decide to deprecate it. Another is if it should be deprecated. Another is what we do in code with a deprecated property.

My default position is that battles lost in standardization processes are battles lost decisively. However, @melvincarvalho has been arguing to me privately that solid:inbox and ldp:inbox are not the same, they are rather different and certainly not owl:equivalentProperty. Now, I say that we should give him time to make his case by writing up use cases where it is shown that they are different.

I think that it is inappropriate to remove a term from a vocabulary once it is included in running code. We can always say

solid:inbox owl:deprecated "true"^^xsd:boolean ;
  rdfs:comment "Old deprecated inbox property"@en .

which would leave no question as to its status. Removing in an open world does not mean deprecated, it means nothing. :-)

But it sounds like we should lend an ear to @melvincarvalho to derive the use cases that sets these two properties apart. It would be for 5.0.0 at the earliest anyway, which is still some time off.

[dmitrizagidulin]

Excellent points @kjetilk.

I think that it is inappropriate to remove a term from a vocabulary once it is included in running code.

This brings up the question - is there running code that uses solid:inbox? (And doesn't need to be updated/rewritten anyway?) I'm not aware of any.

[melvincarvalho]

Right, and we took this into account and updated the specification accordingly:
w3.org/TR/ldn/#target-ownership

Thanks for pointing that out! I think we're agreeing. The two predicates are very similar but have different attack surfaces. That was my original point.

PS didnt know it was in the spec, thanks for adding it! :)

[dmitrizagidulin]

solid : inbox and ldp : inbox are slightly different

No, they're not. The possibility of using ldp:inbox in a header is not a difference. One, it's not a requirement, it's a recommendation, and only done for convenience, to reach a wider audience. Two, rdflib.js treats triples in headers and in the body as equivalent (it parses and adds them to the same graph).

deprecate solid : inbox in future -- unsure why you'd want to -- but could live with it

The reason why is easy. solid:inbox is an old, pre-standardization term. The working group decided to rename it and standardize it. So previous usage should not be encouraged, we need to deprecate it.
Warp is not the reason to keep it around. Warp does not work with our servers currently. It needs to be updated, and changing the vocab is just one update that it needs.

[melvincarvalho]

@RubenVerborgh thank you for looking at this. Our code of conduct requires participants to be respectful to one another. IMHO, volunteers should not be spoken to in that way, or they will be less likely to contribute. I am not inclined to remove my response. I would like this complaint to be treated with the seriousness it deserves.

[melvincarvalho]

A couple of different conversations.

What is important to me is that @rhiaro is imho in breach of our code of conduct. I can say personally as a volunteer that this is a detriment to contribute further.

Let's think about it. Would the commenter talk to Timbl this way?

No apology has been forthcoming, and one is expected.

[melvincarvalho]

Unlocking this thread. I'm keen for a response.

Unless it's unclear, I am keen to escalate.

@RubenVerborgh please dont lock this again

[Mitzi-Laszlo]

@melvincarvalho I'm here to help, best pick this up with me directly. We can discuss any differences in approach and how to go about resolving them.

[dmitrizagidulin]

I'm pretty sure we've decided to replace solid:inbox with ldp:inbox last year (with @timbl's recommendation)?

[melvincarvalho]

@RubenVerborgh we never remove terms in use.

We can deprecate. But that entails what deprecate means, which I think is a valuable thing to do. Certainly it is a misunderstanding if deprecate is equated with deletion.

In this case, I think there's another issue. And that the two terms are not like for like. The common usage of ldp : inbox is as an HTTP header. The common (in fact only) usage of solid : inbox is as a predicate linking user to inbox. The issue arises in the common publisher pattern of adding an ldp : inbox to, say, a profile -- how does a user which is able to form CRUD operations on a file turn it off? They cant. This is an edge case but one that illustrates differences in user control.

[melvincarvalho]

My preferred solution is to add to the spec text saying that solid supports linked data notifications (which has already been done) and using ldn : inbox in the examples (which has already been done). It's possible also to add a note on solid : inbox vocab guiding the user in this regard too. Nothing urgent, at this point, imho.

[akuckartz]

Should they be declared equal using owl:equivalentProperty as a first step?

[melvincarvalho]

@kjetilk well I learn something new every day, I didnt know about owl:deprecated, thanks for pointing it out!

That seems the route.

Indeed, solid : inbox and ldp : inbox are different, but that's quite a subtle point, based on the fact that the former is used as an http header, and the latter is used (only) as an RDF predicate. The difference being is that users that control their file space can turn off anything in RDF, but they cannot turn off headers.

[rhiaro]

The difference being is that users that control their file space can turn off anything in RDF, but they cannot turn off headers.

If you don't trust your POD provider not to set headers you don't agree with, why do you trust them not to meddle with the contents of your RDF files?

(LDN by no means mandates or even encourages use of the inbox in a HTTP header. It simply opens it as an option, to cover the use cases where this is needed, to increase the possibility of adoption even further. We thought this through for months, and the decision is documented extensively in LDN issues and Social WG meeting minutes. To be clear, there is no requirement for Solid servers to implement this.)

[melvincarvalho]

If you don't trust your POD provider not to set headers you don't agree with, why do you trust them not to meddle with the contents of your RDF files?

@rhiaro these are different trust vectors. It can be explained through an example.

Consider a drupal CMS site that has a site wide inbox. I have been told site wise inboxes are a popular pattern in LDN (I could be wrong). Now let's say one day, a solid plugin in drupal becomes all the rage, and people install it for their users, so that people can have control over their data. Suddenly you end up advertising an inbox and routing messages to the wrong place. Additionally, there's fundamentally something different about headers and files. When a file is changed it's easier to notice, you can have a websocket watching it for example in solid. When a header is changed, it's largely undetectable. The LDN spec, understandably wanted to be many things, to many people and has had great success in that. The solid inbox does one thing well.

[melvincarvalho]

decision is documented extensively in LDN issues and Social WG meeting minutes.

Then you'll recall I raised this exact point! :)

[rhiaro]

decision is documented extensively in LDN issues and Social WG meeting minutes.

Then you'll recall I raised this exact point! :)

Right, and we took this into account and updated the specification accordingly:
https://www.w3.org/TR/ldn/#target-ownership

[melvincarvalho]

@RubenVerborgh of course. You need to generalize. Long before LDN I intended to use inbox for payments (I might even have proposed it first, I dont recall). Now, payments must be secure. So imagine site wide attack vectors rerouting payment. It's a nightmare.

More of a nightmare still, is how you handle this with client side apps. You now have to keep track of not only the rdf graph, but also the headers at different times. Try building an app that is LDN compliant with headers and the graph, and get back to me -- you'll see how hard it is!

[melvincarvalho]

Or more simply: no one is creating any triple you don't want, and if they are, we can't stop them magically from doing that just by creating a different URL. And given no argument against OWL equivalence, the one triple is exactly the same as the other anyway.

@RubenVerborgh ive made no comment on owl equivalence, I'll defer to your greater wisdom there. I'm not an owl expert. Was just explaining the slight differences between the two.

[melvincarvalho]

If you are looking for a secure inbox statement, have the user sign it.

Drifting off topic here.

The server shouldn't create any triples the user doesn't want, header or otherwise. End of story?

I said the attack surface increases. @rhiaro has pointed out this is even written up in the spec.

Publishers must be aware that third-party access to headers or content could result in notifications being redirected.

Not good. Especially with notifications such as payments.

Because you have two attack vectors instead of one. And the new attack vector, is to a great extent undetectable. I've worked with commercial grade payment systems of every kind for 20 years. You have to minimize the attack surface every way possible.

[melvincarvalho]

This thread is drifting off topic. Let me reestablish.

• solid : inbox was removed by mistake (this is now fixed)
• solid : inbox and ldp : inbox are slightly different
• it's possible to deprecate solid : inbox in future -- unsure why you'd want to -- but could live with it

[melvincarvalho]

Maybe if you aren't familiar the spec you could stop making declarations about what it says?

@rhiaro this is completely inappropriate

[kjetilk]

Thanks a lot for chiming in, @rhiaro !

@melvincarvalho , I appreciate the point about attack surface, and I think this is a point we should bring into a security review. However,

The difference being is that users that control their file space can turn off anything in RDF, but they cannot turn off headers.

This sounds very much like an implementation detail. It's been a while, so I don't remember the details of the spec, but certainly, our implementation (and spec) can ensure that you can turn off a header whenever they turn off something in the RDF?

[melvincarvalho]

This sounds very much like an implementation detail.

Yes, could be! Just making the case that they are different.

Solid inbox is still in use in apps as far as I am aware. Andrei's apps like warp and inbox iirc. But it's also around in profiles that are created, because it predates ldp : inbox, and every solid profile created had a solid : inbox. So it's in use. Apps could possibly check for both in order to give a consistent UX for our older sign ups (im one!).

[melvincarvalho]

Maybe if you aren't familiar with the spec you could stop making declarations about what it says?

@rhiaro I volunteered my spare time to help your spec and my name is in the acknowledgements. I find your tone disrespectful, and a disincentive to participate as a volunteer. It is made worse by your association with the w3c an solid.

This is the second time I have called you out on tone. Please stop.

Unsure if it is justified, but, if possible I would like to raise a point of order wrt our code of conduct.

cc @timbl @amyvdh

[melvincarvalho]

@RubenVerborgh The technical concern is not addressed in the spec, but rather, it is validated. It's a known security vulnerability which does not exist with solid : inbox. It simply confirms my technical argument.

[rhiaro]

I find your tone disrespectful

Melvin, I find it disrespectful that you waste peoples' time by resurfacing old issues that were discussed and resolved several times already. I find it disrespectful that you make claims with no basis, and post misleading information about technologies or projects publicly. I've lost count of the amount of times I've had to go through this with you, or watched others go through this. Your actions during the years I was taking part in work around Solid and the Social WG have caused me no end of distress and anxiety.

disincentive to participate

I have already quit working on this stuff because of your behaviour. Not really sure who or what you're threatening here.

I'm not interested in discussing this further, nor in taking part in any projects with which you are involved.

[Mitzi-Laszlo]

Hi @rhiaro, Hi @melvincarvalho,
I've had a chance to speak to both of you personally and just wanted to mention that I am here to help talk about any differences in approach. Happy to talk this through together. Reach out to me on the gitter chat or via [email protected] at any point.
Mitzi

[melvincarvalho]

@Mitzi-Laszlo thanks for looking at this. Please let me know the outcome.

[akuckartz]

I think that the original comment by @rhiaro was inappropriate and I appreciate that it was deleted. But I think that the reactions by @melvincarvalho are far more inappropriate and do not help to develop the community. Please stop.

[melvincarvalho]

I sense a willingness to close out this conversation, so I'll go ahead and do that.

https://github.com/solid/community/blob/master/code-of-conduct.md#code-of-conduct

• Communicate and behave with respect, professionalism, fairness, and sensitivity.
• Communicate constructively and avoid demeaning or insulting behavior or language.
• Do not insult or put down other participants.

@rhiaro I would invite you to review the solid code of conduct. I do not feel you have met this standard, in this thread.

Volunteers make many sacrifices to contribute to solid, and are the life blood of open source projects. We strive to be a welcoming project for volunteers, of all kinds, and I personally will stand up for anyone that wishes to do so, always.