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

@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.

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.

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

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.

@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.

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.)

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.

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.

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

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

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

@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!

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! :)

@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.

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.

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.

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 mitzil@inrupt.com at any point.
Mitzi

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

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

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

@RubenVerborgh please dont lock this again

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'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.

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.

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.).