Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 06 08:00
    michielbdejong commented #152
  • Oct 06 07:58
    michielbdejong opened #153
  • Oct 06 07:45
    michielbdejong commented #151
  • Oct 06 07:44
    michielbdejong edited #151
  • Oct 06 07:43
    michielbdejong edited #151
  • Oct 06 07:42
    michielbdejong edited #151
  • Oct 05 12:23
    melvincarvalho commented #152
  • Oct 05 08:06
    michielbdejong edited #152
  • Oct 05 07:56
    michielbdejong opened #152
  • Oct 03 14:01
    michielbdejong closed #150
  • Oct 03 08:00
    michielbdejong commented #149
  • Oct 03 06:35
    michielbdejong commented #149
  • Oct 02 06:20
    michielbdejong edited #151
  • Oct 02 06:20
    michielbdejong commented #151
  • Oct 02 06:18
    michielbdejong commented #151
  • Oct 01 10:22
    ylebre commented #151
  • Sep 30 13:01
    michielbdejong commented #151
  • Sep 30 12:08
    edwardsph commented #151
  • Sep 30 11:32
    csarven edited #150
  • Sep 30 10:22
    michielbdejong opened #151
Melvin Carvalho
@melvincarvalho
@elf-pavlik thank you for the link to the philosophy. Are you arguing that different mime types may give back different triples? If so, IMHO, 0.9.x becomes more difficult to test.
elf Pavlik
@elf-pavlik
I'm not arguing anything, just recalled a prior conversation that seems relevant so decided to drop that link.
Melvin Carvalho
@melvincarvalho

Add that all RDF representations should represent the same graph

OK, I like this ^^

Thanks for the pointer @elf-pavlik !

Melvin Carvalho
@melvincarvalho
Unresolved for 2 years. Sigh.
Michiel de Jong
@michielbdejong
Still, we can add some optional tests that check to which extent a pod on a given server implementation is usable for hosting HTML. 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)
Melvin Carvalho
@melvincarvalho
@michielbdejong love it! I'd be more focused on GET to start with, as that seems more fundamental.
inboxes have always been a gaping security hole in Solid, I think that needs a LOT of thought
good thought, tho!
Melvin Carvalho
@melvincarvalho
so one thing we really really wanted to do after 0.7 is figure out who the sender was to your inbox
otherwise you could just have anyone send anything there, and that attracts the bad guys ... mastodon solves this by signing, but afaik this didnt get solved in solid
but in any case, I think that the test suite can handle GET and POST as separate tests ... with GET itself being valuable
Melvin Carvalho
@melvincarvalho
POSTing to an append only inbox is an interesting problem. I've always been of the opinion that ldp:inbox is 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:inbox and 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.
There may be some ways to add inbox tests to the test suite but it's quite nuanced imo
you do raise a v interesting point tho, and that is what if an .html file ends up in your inbox
Melvin Carvalho
@melvincarvalho
I think for that, whatever's in the data island should be considered the data
But we can so something simpler for GET. The aim is to test the extent to which content negotiation is working, or not working, on a server. The test would compare the triples returned for different mime types that the servers accept.
Michiel de Jong
@michielbdejong
I added some first tests for webhooks and some partial tests for secure websockets to solid-crud-tests. I'm still debugging some npm dependencies but should hopefully have it published in a usable version soon.
Fred Gibson
@gibsonf1
I'm definitely all for specs around implementation run inbox agents (we are adding an active process per pod to manage things as it is)
elf Pavlik
@elf-pavlik
IMO we should look more into an outbox approach (not necessarily ActivityPub Outbox), having Solid Notifications in place a peer could simply subscribe to an outbox that was created specifically for them.
I know this conversation isn't for this channel, but I plan to share some experience of how in SAI we use notifications for agents to subscribe to reciprocal Social Agent Registrations which can be extended further in outbox direction. If someone needs more details sooner than later please don't hesitate to ask on https://gitter.im/solid/data-interoperability-panel
TL;DR you will not get spam unless you go grab some yourself from a spammy outbox
Melvin Carvalho
@melvincarvalho
agents are really hard
but they can actually run tests, so that's a plus
Melvin Carvalho
@melvincarvalho
in a nutshell, processes are local things, but solid is more of a web visibility type system because it's cross origin, therefore, to have a well aligned agent, the scope of the agent benefits from being aligned to the scope of the web, which is quite a hard thing conceptually to get your head around -- but you need it otherwise you end up spending a lot of time managing processes, rather than letting processes and data interact
making an agent that runs the test suite might be a marker of success
Melvin Carvalho
@melvincarvalho

@elf-pavlik nice thoughts regarding outbox! I had some similar early ideas:

https://microfed.org/

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.

Michiel de Jong
@michielbdejong
I think it's useful if this channel is mainly about how to write tests for things that came out of discussions that happened elsewhere. Mainly we build tests for the different spec requirements and for features that the spec mentions as optional. But sometimes we build test for something that was entirely experimental. For instance https://github.com/solid-contrib/monetization-tests has tests around https://github.com/solid-contrib/webmonetization . So in that example we would use this Gitter channel to discuss the monetization-tests but not to discuss webmonetization.
I'm still quite busy with the v0.9.1 tests and the webhook tests but if and when I have some time left over I can look at writing some optional tests that check to which extent a pod on a given server implementation is usable for hosting HTML and/or other things people are interested in.
Melvin Carvalho
@melvincarvalho
sure, there is no rush ... the conneg issue, and related issues (e.g. etags) has been open 3 years, so i dont expect results over night :) That's it's on the radar is great
ie how do you marry together content negotiation and etags
Melvin Carvalho
@melvincarvalho
key thing to test is that the same URI doesnt give back different triples depending on mime type, as that is a clear bug, and it's almost everywhere in solid servers today
Melvin Carvalho
@melvincarvalho
it looks like solid might be moving to 2.x
Sarven Capadisli
@csarven
I've been thinking about the test-suite-panel's meetings. I think we can still do meetings on their own, but I thought the CG can benefit from taking up topics of interest to the CG, e.g., call for things, status updates, developments in process/procedures, or anything generally of interest to the CG within the scope of the work.
Michiel de Jong
@michielbdejong
Yes, good idea! Let's merge it. That will help us keep our priorities aligned with what people need from us (short term) / what people generally think is needed from us in the interest of Solid (long term).
I realise I should prepare a little report about what I've been working on last week (i.e. v0.9.1 tests and WebHooks tests) and how it fits in the bigger picture.
I can present that at the next CG meeting and invite questions / comments.
Sarven Capadisli
@csarven
We still stick to test-suite-panel-charter and work out our deliverables. We can only take up some of the activities/considerations in the CG-weekly because of available time.
Michiel de Jong
@michielbdejong
yes
it should only be things that fall inside our charter, of course, or at least things that don't distract us from our charter tasks.
Michiel de Jong
@michielbdejong
Short status update from me and invitation for discussion:
solid-contrib/test-suite#152
I don't have the v"next" tests ready yet but I think a big part of the code is in place, I'll try to complete those soon.
Melvin Carvalho
@melvincarvalho

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

Melvin Carvalho
@melvincarvalho

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

Melvin Carvalho
@melvincarvalho

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.

Melvin Carvalho
@melvincarvalho

insecure websockets will be dropped

unclear that this is an optimal design choice because insecure websockets are useful for testing on localhost. Is there a specific advantage of wss, such at authentication? Or is it just MITM protection?

Melvin Carvalho
@melvincarvalho
It might be nice to allow ws:// for local testing?
Michiel de Jong
@michielbdejong
Yes, sorry, the 'insecure' vs 'secure' websockets there refers to nodeSolidServer/node-solid-ws#1 which is now resolved with the new Notifications spec.
Melvin Carvalho
@melvincarvalho
Ah sorry, got it. So websocket + ACL. Very nice idea. This could be used in many projects.
good tool for testing websockets