Website: https://solid.mit.edu/ and https://solidproject.org/ - Repos: https://github.com/solid/ - Forum: https://forum.solidproject.org/
May 27 2019 06:08
User @Mitzi-Laszlo unbanned @in1t3r
May 23 2019 06:49
@Mitzi-Laszlo banned @in1t3r
May 16 2019 09:49
@Mitzi-Laszlo banned @mediaprophet
Feb 01 2019 22:04
User @melvincarvalho unbanned @namedgraph_twitter
Feb 01 2019 21:49
@melvincarvalho banned @namedgraph_twitter
@timbl are you by any chance going to be in town for our event at May 13? I have received tremendous interest from local developers here
Hi Li Lu, Tim will be speaking in Toronto around that time but best not to plan around his attendance of Solid Toronto, happy to set up another chat and go through the Solid Toronto plans and possible content with you if that's helpful
Hey Mitzi! Thank you for the offering! We are planning the event assuming Tim’s absence. Just can’t help with the excitement that he might be in town. We will have the content flow figured about mid week and would love to get your feedback once the flow is set! Thank you!
Hey, just got off call with John and Kelly from @RubenVerborgh connecting us over the POD sync/replication (across different POD providers) and POD encryption (so POD providers can't read data), I have things ready to do this now just need to spearhead it in with somebody who can get me acquainted with codebase nuances... who is interested in SOLID sync & encryption!?
oh hey... it's mark from gundb
What do you think about caching private data in the localStorage? The way I understand localStorage, it shares it's data with all apps from which have the same domain. This would mean, that if the user has installed two different apps on his pod (or uses them from some kind of appstore), they could access the data from each other regardless of their unique access constraints. Furthermore, they could use the login credentials stored by solid-auth-client even if they weren't given any permission
I've read here, that "Two actors in the Web platform that share an origin are assumed to trust each other and to have the same authority", but I don't really think this applies for solid as giving unique permission control per app is (imo) a key feature of it. That they share the same host doesn't mean that they even know of each other if we think of storing apps on the own pod or using some kind of app store
But Solid relies on the Origin as well, so if two apps share an origin they are actually one app from solid point of view
Yes, I forgot that. But this suggests
... that we should host each app on its own (sub) domain. So hosting all the apps I use on my pod is a bad idea then...?
It is reasonable to host apps made by the same person in the same domain. As you are trusting that person I suppose. Unless you give the two apps different access. Then they each have to be on different domains
That design is forced on us by the browser Same Origin Policy
Ah no it's basically my undergrad students being assigned the task to build a blog app on Solid
Bonus point: demonstrate consuming of data created by another application :)
@Otto-AA the per-orign localStorage cache is working now in solid-rest-browser
Where can I ask a fundamental newbie question such as: why distribute data instead of creating a coop to own and control data, and sell memberships in it? (solve data ownership with ownership rather than technology). Food for thought, or indigestion (sorry)?
Better yet, support overpayments and.change the available solutions for those who do some sort of.work online, then use transactional incomes to ensure no one needs to sell personal data whatsoever... Billions of people, trillions of things, shouldn't take much to get an hourly wage for good work... other than the investment required to make the technology needed for said new forms of taxable revenue option. Obviously, the issues people had since exodus in trying to get paid for old types of work, like that of a stonemason, are now fairly well resolved. Perhaps the problem is that we need to bring about a global web strike!
gitter is a bit difficult to follow when discussions get lengthy
Should say, micropayments, not overpayments. So many jobs to do, there's a glut of jobs, no shortage of them. Just a complete lack of suitable financial instruments and related support infrastructure.
Floor price for a micropayment should be as low as possible, incorporating the cost of the energy consumed to support it.
https://digiconomist.net/bitcoin-energy-consumption won't work. I've been working to figure how how to share the revenue sourced from say, a 2c app, across hundreds of contributors providing thousands of hours work, to.make it happen, who say, want to get paid $50 per hour (only), for having done the work (a very basic example), then the app might be made free, via an approach I called last year, software as a utility...
Noting, many models can be defined using rdf / semweb goodness...
@Mitzi-Laszlo I'm as concerned as you are for both legal and technical. Please reference my link above.
My point is that a data coop solves both legal and technical aspects without splintering the data. Consolidation does not equate to exploitation, if we own the consolidator (a standard legal coop).
And nobody should stop you in trying to create that co-op
Maybe Solid can be part of that even, it is about social linked data after all
The focus here is on developing Solid into becoming what it can become - a decentralized ecosystem where people control their data
And all of the services and innovations we hope for to be part of that
In any case, I think at the center of it should be interoperability - services able to work on the same set of data, giving people more choices in how they consume and produce their data
I had a chat recenntly with a lawyer who hd been heavily involved in the uk Coop which in nowadays mostly food shops but at one point was many things. He thought that looking at coop legal systems for Solid data storage could be a good idea.
@timbl interesting! something I was thinking of is that I'd like to see local libraries have more involvement in open services that support features in the solid core app set that should be available to everyone for free.
Mark Hughes (happybeing)
Anyone around to think about a node packaging issue with me? I'm trying to build a module that has a circular dependency, i.e. a fork of solid-auth-client, where: solid-auth-client -> safenetworkjs -> rdflib -> solid-auth-client. I don't think this can work, but would love to hear if there's a way to do this.
Mark Hughes (happybeing)
Would it be possible to make rdflib external to safenetworkjs (so bundling leaves it unresolved) and have solid-auth-client provide rdflib for safenetworkjs to pick up? I don't know if that even makes sense, but I see that rdflib seems to do something like this when building a browser bundle, but not for this reason (here).
NPM should manage the circular dependenctybut I am not an expert
Mark Hughes (happybeing)
Thanks Tim. I get a memory allocation error during the webpack bundling, which doesn't happen if I break the circle so I'm thinking it's related. I have found some suggestions on StackExchange so have things to try.
I thought NPM should handle that as well, but if method foo in package A is calling method bar in package B, and method bar is calling method foo, you might get a circular dependency that never exits - that isn't the case here, is it?
Mark Hughes (happybeing)
I'm not 100% sure so am going to use my sophisticated debugging technique of prodding and poking until it works [cough].