ldp:inboxis a security problem. For example in that the domain owner can set a header for inbox, which can conflict with user created data, and the user has no way to turn it off. This is one reason I dont like
ldp:inboxand preferred our original
solid:inbox. I came to the conclusion after working a lot with inboxes in solid that it was very hard to test. I hit a wall and had to go away and rethink the whole problem space. My conclusion was that you need something beyond solid, and that is autonomous agents, which are able to monitor an inbox for new entries and then process them on behalf of the user.
@elf-pavlik nice thoughts regarding outbox! I had some similar early ideas:
One question is who can send to an outbox and how?
I know this conversation isn't for this channel
IMHO channel should be for anything that we can usefully write a test for, and related matters. But Michiel can guide us on that, as he's built a lot of great communities :)
There are also some security considerations, for instance if someone is able to POST some web page to your inbox and then convince you to open it with your browser (very similar to when you open a spam email message using a webmail client)
I thought for quite a while about this. It's a really excellent point. So you have data and apps. Apps have a bigger security surface than data. In the case of html you can have both. One mitigation is to trust a certain app, a certain page, a certain group, a certain set of pages (resource / container / origin || integrity / creator) -- seems various strategies, since apps are executable, we may need an extra layer of security. But in any case we need apps, so worth doing over time. But what we can test is whether or not the data is consistent. Right now html/turtle/json-ld is not consistent in solid servers, and that's a problem.
v"next"tests ready yet but I think a big part of the code is in place, I'll try to complete those soon.
but I thought the CG can benefit from taking up topics of interest to the CG
I actually started that CG. The idea was to enable threaded conversations, this was before gitter allowed them. More activity there is welcome, because it's quite a diverse audience, all interested in solid. So +1 that :)
anything generally of interest to the CG within the scope of the work
Originally Solid was designed as a very modular thing. Not monolithic at all. The test suite captures that really well, imho where certain functions can be tested which allow certain features, and together they are even better. IMHO test suite is very much in scope and a one of the most pragmatic tools to achieve progress
apps and servers should still adhere to v0.9.0 in production
apps and servers should support previous versions in production unless it clashes with the requirement to support the latest released spec version
@michielbdejong very very unfortunately 0.9.x is not backwards compatible with previous versions. App designers definitely do NOT want to build on an unstable specification. The earth is deeply salted with developer disappointment on that front. We need a way of messaging the developer community to say when the spec is relatively stable and that there will not be breaking changes. Perhaps solid 2.x can be this.