profile
viewpoint
Michiel de Jong michielbdejong (independent) Utrecht (NL) https://michielbdejong.com/ Independent programmer.

linkeddata/rdflib.js 440

Linked Data API for JavaScript

ambanum/CGUs 8

Tracks and makes visible changes to the Terms Of Service of the main online services.

michielbdejong/balimich 6

deprecated, see https://github.com/unhosted/unhosted/ instead

ledgerloops/ledgerloops.com 4

Contents of https://ledgerloops.com

michielbdejong/bogor-angkot-gtfs 3

A gtfs feed for public minibuses ("angkots") in Bogor, Indonesia.

ledgerloops/hubbie 2

WebSocket manager

michielbdejong/backtofront 1

rapid prototyping tool for teleporting nodejs modules straight into your client-side namespace

michielbdejong/Bookmark-App 1

An unhosted Bookmark App

michielbdejong/browserid-session 1

a BrowserID-based session handler for https://github.com/fkooman/phpvoot

startedory/hydra-maester

started time in 38 minutes

startedlelinhtinh/de4js

started time in an hour

startedxapix-io/matchete

started time in an hour

issue commentsolid/node-solid-server

Support SPARQL GET requests as documented on solid-spec

For anyone wondering, we decided to close this because SPARQL GET has been removed from the spec. So it doesn't need to be implemented anymore.

NoelDeMartin

comment created time in 3 hours

startedpagopa/io-app

started time in 3 hours

startedheroku/heroku-pg-extras

started time in 3 hours

startedrkalis/truffle-assertions

started time in 4 hours

issue commentsolid/solid-rest

Reconsider handler initialization

NWjs (https://nwjs.io) was the original electron. One of their alumni was responsible for much of the work on electron (and it got pretty acrimonious). It has both window and node environments together. Thats why I am proposing a better check model for handler association. I can make a PR for you to review, since I think it would be a non-breaking change otherwise!!!

CxRes

comment created time in 4 hours

startedMaartenGr/PolyFuzz

started time in 4 hours

issue commentsolid/solid-rest

Reconsider handler initialization

Sorry, this post goes off topic into the plugin issue. I'll return to it in the next comment...

Maybe I'm wrong about how conditional requires work, but my impression is that file.js and the other plugins are only imported automatically if no other handlers are supplied.

That is only true if you are invoking the code from node (and then too the code exists in node_modules). Bundlers like Webpack and Rollup will pull all the requires unless you specifically ask it not to (which requires you to dig in and manually identify these require calls). I have all this code in my bundle even when I do not want to use most of these fetchers. I would like to avoid that!

I do not understand "install solid-node-client ... as plugins".

That clarifies my mental model a bit (perhaps influenced by solid-auth-cli, or my impression of it). Hopefully, I can now explain my idea better.

In my model, I would ideally like to see a fetcher manager, lets call it solid-fetch-manager wherein http-fetcher, file-fetcher, localstorage-fetcher etc. each will be a plugin. Now, I imagine 2 modes:

  1. Manual mode: wherein developer will choose what fetcher they want. (It is not inconceivable if solid catches on, a developer may create an app that only stores data locally for a session using say, a local-storage fetcher (and not even use a http-fetcher). Or another protocol instead of http catches on? Or I want a desktop only app! Ultimately, it is solid that matters as the standard for data communication not the transport/storage, that it is built first on http is incidental. And solid-rest is proof of that imho!)
  2. Automatic mode: where based on the protocol on the address, the fetcher-manager installs or downloads the correct fetcher from a CDN. (would work extremely well with something like deno)

Ultimately, I am trying avoid any bloat being added due presumptions made, even if it is a completely reasonable presumption like supporting http: and file: out of the box. To support these assumptions, we can simply install http: and file: fetchers anytime one installs the solid-fetch-manager.

Re: Example Just one pedantic point which drags on the plugin issue... it is generally a bad idea in my experience to call files inside a library ie solid-rest/src/localStorage (since they might get remapped/renamed at some point, I have filed such bugs before). Partially, we can fix this with the exports property in package.json, but really, I think it is a sign that they need to be in separate repos!

CxRes

comment created time in 4 hours

startedphotoprism/photoprism

started time in 4 hours

startedabesto/rktrl

started time in 4 hours

push eventambanum/CGUs

Clément Biron

commit sha dff11202597d2c3068d0ed9ba1715e10b9c47bd3

Rename services ID

view details

push time in 4 hours

issue commentsolid/solid-rest

Reconsider handler initialization

I do not understand "install solid-node-client ... as plugins". Solid-node-client is not a plugin to solid-rest, it's the other way around. Here is the chain as I see it:

define a non-http-fetcher (solid-rest+plugins)                                  
define an http-fetcher (solid-auth-fetcher)                                     
create a hybrid fetcher that uses both (solid-node-client)                      
specify another library's fetcher as that hybrid (rdlib,solid-file-client,etc.) 
CxRes

comment created time in 5 hours

push eventambanum/CGUs

Clément Biron

commit sha 76137365fa489c94c8bf2ca7554cfbcb950fea6e

Rename services ID

view details

push time in 5 hours

issue commentsolid/solid-rest

Reconsider handler initialization

Solid-Node-Client does nothing but add solid-rest's fetch to whatever the underlying auth is. Currently that is solid-auth-fetcher but if and when there is a solid-client-authn-node, it will switch to that. If one doesn't need solid-rest, one can use either of those auth libraries directly without solid-node-client.

The failure in nwjs (which I had never heard of but looks interesting) is concerning. My feeling is that I should add a note in the documentation that if you are operating in a mixed environment such as nwjs or electron, you MUST supply your own handler(s) in the call to new SolidRest(), see below for an example.

I agree that solid-rest should be as light as possible, but for backward compatibility and general principles, I would like it to function out of the box for file:// requests in node. Maybe I'm wrong about how conditional requires work, but my impression is that file.js and the other plugins are only imported automatically if no other handlers are supplied.

Rdflib is in rapid development and so problems with including it may be temporary. I encourage you to raise an issue or go to the rdflib chatroom if you are having diffuculty with it.

For cases in which the user does not want the built-in plugins, passing in a handler will override them and they will not be loaded. For example, this instantiation would use localStorage.js but not file.js.

const SolidRest = require('solid-rest')                                         
const LS = require('solid-rest/src/localStorage')                               
const rest = new SolidRest({                                                    
  handlers : [new LS()]                                                         
}); 

There is a working example of doing this in a browser at solid-rest/tests/browser-test.html. It instantiates the object like so:

<script src="../bundles/browserfs.min.js"></script>
<script src="../src/browserFS.js"></script>  
<script src="../dist/browser/solid-rest.js"></script>
<script>
const rest = new SolidRest({
  handlers : [new SolidBrowserFS()]
})
...
CxRes

comment created time in 5 hours

issue commentsolid/solid-node-client

Crashes with a null cookie

This actually seems identical to #10. (Should have read more carefully)

CxRes

comment created time in 5 hours

push eventambanum/CGUs

Nicolas Dupont

commit sha 0e41ec891ecd071c0fb3d20197f0a2f9fa2265a3

Services imported from tosback2 using https://github.com/ambanum/TOSBack-CGUs-bridge

view details

Nicolas Dupont

commit sha 088aecb63d01a34191711d308a2c6d9f6e15c458

Update ACDelco Privacy Policy

view details

Nicolas Dupont

commit sha 01d05a5fe22c502e0d804d84ffb12472e35be22d

Update Aetna Privacy Policy

view details

Nicolas Dupont

commit sha 6356c4d9f7676c6ed5e022e373170d39eea96c16

Update Alibaba selectors Update Alibaba Privacy Policy Update Alibaba Copyright Complains Policy Update Alibaba Terms of Service

view details

Nicolas Dupont

commit sha d6bca3c4c825ea293ceabf01f61fa33ef9e9dac5

Update Allrecipes Terms of Service

view details

Nicolas Dupont

commit sha 2f4d04e95e2518982840412b5628a7c79b8d00a1

Start tracking Allrecipes Privacy Policy

view details

Nicolas Dupont

commit sha 0580147234e3541c615011f357a12006db71f9de

Update Alibaba selectors Include official titles of documents Update Alibaba Privacy Policy Update Alibaba Copyright Complains Policy Update Alibaba Terms of Service

view details

Nicolas Dupont

commit sha eede8d1b23d1a6b134c4398d7c2c8e7ff5fc9282

Remove improperly declared Android service Tracked only Google Privacy Policy

view details

Nicolas Dupont

commit sha fdd32cb984c61b2ee4639f149dbf6b3910228827

Track UK rather than US terms in Apple Game Center Hope they are closer to EEA terms Update Apple Game Center Terms of Service

view details

Nicolas Dupont

commit sha 6f516eee7a64fa0f677ae26c91ff57e1ab358220

Update Academia.edu name and ID

view details

Nicolas Dupont

commit sha c0b0d2e56e6350af45e016ae5b13c03232dc9db4

Update Alibaba.com name and ID

view details

Nicolas Dupont

commit sha 106b65434a83a5868ebca7c891f3fa2633cf0507

Update Amazon.com name and ID

view details

Nicolas Dupont

commit sha ba79369947575a10962c7ce4209c17e7f3765cad

Update Alexa name and ID

view details

Nicolas Dupont

commit sha 10ecf64b6a3c497956c6d278063e288c3569dae0

Update Amazon Appstore name and ID

view details

Nicolas Dupont

commit sha 312c9119325a8937307df83fa9d96158947c1b33

Update Amazon Coins name and ID

view details

Nicolas Dupont

commit sha 8bb29aa5c09295b3f7010abeb5771b33db432294

Update Amazon Device name and ID

view details

Nicolas Dupont

commit sha d8728006e44cffb86b3d1789d6aa555d25cbbde0

Update AmazonPhotos name and ID

view details

Nicolas Dupont

commit sha cbc99d2e27ceed5869a666224d42c50915dfeed4

Update Amazon Kindle Store name and ID

view details

Nicolas Dupont

commit sha 48a13a34f3b2a5a74e49b04cb861157be099cea9

Update Amazon E-Reader and Fire Tablet name and ID

view details

Nicolas Dupont

commit sha 8a42eba8468233d730bd7b064b00be6e6ad7d63e

Update Amazon Monthly Payments name and ID

view details

push time in 5 hours

issue openedsolid/solid-node-client

Crashes with a null cookie

When I try to use solid-node-client in a nwjs environment, inside SolidNodeClient.prototype._getAuthFetcher, the cookie is set to null and then the program crashes since getAuthFetcher() expects a cookie to have length property. This might be a bug in solid-auth-fetcher and/or this call should exist in try catch block (in case authentication fails, though I am not sure why it would fail!).

Strangely, it works fine when I run the same code in Node LTS! I am not sure what trips the code up, I would appreciate any suggestions where to look...

created time in 5 hours

push eventambanum/CGUs

Clément Biron

commit sha c135f1ccc44784957378709bcd1502cee3a0cd40

Update Hsbc service

view details

Clément Biron

commit sha 145024788e9d5053ed438625480e3a3001615acf

Update Ign service

view details

Clément Biron

commit sha a8e86da31a0388d3a49b7c730d04f716265f1e0f

Update Imdb service

view details

Clément Biron

commit sha 7b92df4a5da3bc5f0b6dcda1d8bf6fe457024e5a

Remove Live service

view details

Clément Biron

commit sha c98f2b4cec67c8236732deed4bbb6d666b838369

Update Logitech service

view details

Clément Biron

commit sha 0a73495993f509c4f21b2398006209956590ce92

Update Microsoft service

view details

push time in 5 hours

issue commentsolid/solid-rest

Reconsider handler initialization

The way it works is that if the user does not pass in one or more handlers, it checks the operating environment and pulls in the default handlers for that environment.

I think this could do with some improvement (since it fails in nwjs), by checking for node and process objects for instance. Just because window is undefined is no reason node.fs is defined or vice-versa. Check should be something on the lines of: Is node defined? then FS; Is localStorage defined? then localStorage else Memory.

In my case of nwjs, it goes false on typeof 'window' === undefined , then fails the try because browserFS is not a constructor (for reasons I do not understand as of now) and ultimately crashes at handler.forEach because handlers is initialized as null! I am guessing, the bug is that handlers should at least be an empty array. But we came to that only because we could not define any handler at all!

Meanwhile could you please point me to the handler invocation in Data-Kitchen. At least, I can side-step the issue that way for now.

There is nothing in solid-rest that requires solid-node-client. Its the other way around that I have an issue with, ie solid-node-client requires solid-rest. So just to use solid-node-client (essentially the auth and fetch in it with say, solid-file-client) I have to pull in all of solid-rest. Let me put this in another way: In my ideal scenario (this is my opinion, though held strongly), solid-rest would be a thin wrapper that passes controls to different protocols and one would install solid-node-client or solid-localstorage etc. as plugins. Currently, fs: or app:/ls/ etc. come baked in with solid-rest (even if I do not want to support one of these protocols in my end product or any for that matter) which in turn come baked in when I install solid-node-client. It is a classic banana-gorilla problem!

If there is another mechanism you have in mind or currently exists that I am missing, I am all ears!!!!!

Additionally, rdflib currently... I'll come to that in a separate issue. rdflib uses outdated deps and I have had Rollup screaming madly at me last night when I activate it. I hope we can find some other way to enable PATCH.

CxRes

comment created time in 6 hours

push eventambanum/CGUs

Clément Biron

commit sha 9ee0d2e3ca1eae8e0c011a1876e618805e48e99b

Update Evernote service

view details

Clément Biron

commit sha 6bd13bb68c6c82824116dad67a889a458d54ded1

Update Fedex service

view details

Clément Biron

commit sha 33c7298d57043f975f85ff3488466b7afd6c9a37

Update Forbes service

view details

Clément Biron

commit sha e3fcfec043da3c34eb82b4ac5c068c246bb5f38c

Update Foxnews service

view details

Clément Biron

commit sha 809bae927588ea44c995d7d038ccea8b191289a6

Update Ft service

view details

Clément Biron

commit sha c23fa894dad7dedb67a56c71149505029e246281

Update Gartner service

view details

Clément Biron

commit sha c9eea5d922994b2ab6fc516328c319cf9d3c132d

Update Github service

view details

Clément Biron

commit sha c4f62bf0588551b168693f6983efae2b12ad9976

Update Gitlab service

view details

Clément Biron

commit sha a14b743b077cef84f20af63ba4d6d0d6668d4abc

Update Gmail service

view details

push time in 6 hours

issue commentsolid/solid-rest

Reconsider handler initialization

I think you have misread the code for the handlers. (It's a bit messed up because I had to retrofit some things to maintain backwards compatibility and also handle a passed in rdflib for patch.) The way it works is that if the user does not pass in one or more handlers, it checks the operating environment and pulls in the default handlers for that environment. However, if the user does pass in some handlers, it uses those and does not check the environment at all. So in Data-Kitcehn (an electron app), I pass in both the nodejs and the browser-based handlers in the call to new SolidRest() because it is capable of operating in both environments.

I am behind on documenting Solid-Rest. I need to do a lot of work there and mentioning options.handlers is a big one.

I am unclear what you mean about decoupling from solid-node-client. There is nothing in solid-rest that requires solid-node-client and solid-rest is quite capable of operating without it. And in solid-node-client (although undocumented as yet, I just put this feature in) you can pass in any fetch handler with the call to new SolidNodeClient. Additionally, rdflib currently looks for global.solidFetcher allowing users to define the fetcher at the top of their app rather than passing it in when creating a fetcher. Solid-client-authn-nodejs (if it ever comes out) also plans to look for a global fetch to allow users to override the built-in. So it seems to me that an app can easily mix and match auth/login libraries and fetch libraries. Am I missing something?

If I've misunderstood your suggestions or my response doesn't answer them, please ask again.

CxRes

comment created time in 7 hours

push eventambanum/CGUs

Clément Biron

commit sha 4db5f237155df1f0c537f1494f09c7af6c4d5b24

Update CVS service

view details

Clément Biron

commit sha efc76d04cf1dac67c9a47678acb911887eac16ad

Update Dailymail service

view details

Clément Biron

commit sha eaafbdf23f58aa860a51e2e0933efca99376bddb

Update Dailymotion service

view details

Clément Biron

commit sha 1f0eec11650246f9979abe7f06302dde812ceb98

Update Discordapp service

view details

Clément Biron

commit sha 8c29e5e3a14f1a8c85001f1ff7a319e98b67b122

Update Disqus service

view details

Clément Biron

commit sha c7c19a48ca42d6183298d6f16ba41bb3948ea19f

Update Duckduckgo service

view details

push time in 7 hours

issue closedsolid/solidcommunity.net

Registration email sends tracking pixel

See https://github.com/solid/node-solid-server/issues/1532 (probably not an NSS issue, but impacts inrupt.net as well.

closed time in 8 hours

jeff-zucker

push eventambanum/CGUs

Clément Biron

commit sha 92eeca4e3190aee7f64d293da276c823f203b130

Remove Blogspot service

view details

Clément Biron

commit sha cb0684fca927dbb3aaaba2c749ad3d5ae1eb4de9

Update Cloudant service

view details

Clément Biron

commit sha 8513f12ac9f24b2cfcaebd73308c80215535f551

Update CNN service

view details

Clément Biron

commit sha 96d8d2cdb26da6382908801b28e80f6a4b8af30c

Update CommentCaMarche service

view details

Clément Biron

commit sha 447236522615983ce8212223b09e8c02295b3228

Update Couchsurfing service

view details

push time in 8 hours

issue commentsolid/node-solid-server

Server emails include tracking pixels

The tracking pixel was not used by Inrupt for any purpose, and so has been removed from the password reset email.

Thanks for bringing this to our attention.

jeff-zucker

comment created time in 9 hours

issue openedsolid/solid-rest

Reconsider handler initialization

Currently, handler initialization is based on checking the window object. I presume this has to do with detecting if the environment is a browser. However, this check is a problem in nwjs/electron environments where both window and node are defined. In such cases we still want to create file handlers and can even use native localstorage of the browser. At least checks should be made for both window and process.

I am not sure of the best strategy to manage this tough and would like to hear a bit more about the design intent in automatically initializing handlers. I see that one can pass options through solid-node-client (incl. options.handlers) but these are not documented. That is why I have refrained from putting up a PR!

Somewhat unrelated but relevant to the issue, I think in the long term solid-rest should be decoupled from solid-node-client (and other providers should be decoupled as well, as this list will become unwieldingly large if this project takes off). Each type of source then should be a plugin that is invoked based on user-installation (perhaps done so automatically on first invocation of the scheme) and url scheme. In fact, this is the approach I am taking in including solid in my application. Please consider this in your future plans!

created time in 9 hours

issue commentsolid/node-solid-server

Unknown content types are served as text/plain

My testing currently shows that PUT without a specified content-type sets the content-type to text/plain and POST with no content-type sets the content type to application/octet-stream. Both should fail with 415.

Both should be 400 since the requests are using either an invalid Content-Type field-value or without the Content-Type header:

https://github.com/solid/node-solid-server/pull/1526#issuecomment-734441867 https://github.com/solid/specification/issues/211#issuecomment-734229722

415 would be appropriate for a good requests where the server doesn't support the media-type:

https://github.com/solid/node-solid-server/pull/1526#issuecomment-734497253

jeff-zucker

comment created time in 10 hours

fork dtantsur/baremetal-operator

Bare metal host provisioning integration for Kubernetes

fork in 10 hours

more