solid
design-reviews
solid | design-reviews | |
---|---|---|
117 | 9 | |
8,173 | 317 | |
0.0% | 0.9% | |
0.0 | 4.7 | |
over 1 year ago | about 2 months ago | |
HTML | JavaScript | |
MIT License | Creative Commons Zero v1.0 Universal |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
solid
-
Simple Lasts Longer
This doesn't support the various consumer cloud storage APIs, but you've just reminded me of a project I ran into years ago that seems to still be around: https://remotestorage.io/
There's also Solid which attempts to do something similar: https://solidproject.org/
-
The current state of the Web and what is the next step in its evolution.
It is surprising to me this is not talked about more. I see little to none online news, podcasts, YouTube videos or anything else where this is discussed. I only found out about it because of research I did on Tim Berners-Lee in preparation for a Career Day talk at my kids middle school. Otherwise I would have probably not known about it still today. And even after I found out and started watching YouTube videos on the topic, YouTube won't even suggest any related videos about it even after already watching multiple videos on the subject (Web 3.0, Solid Project, Decentralized Web...etc).. is Big Tech trying to keep the web from evolving into what Sir Tim Berners-Lee is proposing?
-
Write libraries instead of services, where possible
It's only an unreasonable amount of work if you assume that the user is managing a separate storage backend for each library. If you take the Tim Berners-Lee approach (re: https://solidproject.org/) then each user is only managing one storage backend: the one that stores their data. The marginal cost of hooking in one more library low.
We just have to get a little more fed up with all of these services and then the initial cost of setting it up in the first place will be worth it. Any day now...
-
Manas: Storage servers confirming to Solid protocol
Solid is a web native protocol to enable interoperable, read-write, collaborative, and decentralized web, truer to web's original vision.
-
Manas: Solid protocol storage server in Rust for decentralized web
Manas project(https://github.com/manomayam/manas/tree/main) aims to create a modular framework and ecosystem to create correct, robust storage servers adhering to Solid protocol in rust.
[Solid](https://solidproject.org/) is a web native protocol to enable interoperable, read-write, collaborative, and decentralized web, truer to web's original vision.
Solid adds to existing Web standards to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs.
-
My vision of the semantic web...correct me if I'm wrong.
You're describing Solid, not the Semantic Web. Granted, Solid uses Semantic technologies to achieve it. https://solidproject.org/
- Threads : à peine lancé, le concurrent de Twitter crée par Facebook compte 10 millions de membres
-
The problem with federated web apps
Tim Berners-Lee's Solid project is working on that. Put data in "pods" that are stored on pod servers, which are federated. You can self-host.
It could be a federated layer of identity & personal content decoupled from social platforms.
https://solidproject.org/
-
Update of the RDF and SPARQL (RDF star) families of specifications
Check out https://solidproject.org (If you want a short intro I recently gave a ~30min talk about it: https://noeldemartin.com/fosdem)
- Solid, a spec that lets people store their data securely in decentralized Pods
design-reviews
-
Modern CSS One-Line Upgrades – Modern CSS Solutions
> The other value of pretty specifically addresses preventing orphans and can be more broadly applied. The algorithm behind pretty will evaluate the last four lines in a text block to work out adjustments as needed to ensure the last line has two or more words.
This is very, very badly wrong. `text-wrap-style: pretty` is explicitly not about orphans and does not have a defined algorithm. It’s about prettiness, a subjective thing that will have different interpretations in different browsers and over time, and this is extremely deliberate. What the author has described is what Chromium has implemented at this time.
All the spec says is <https://www.w3.org/TR/css-text-4/#valdef-text-wrap-style-pre...>, that `text-wrap-style: pretty` “Specifies the UA should bias for better layout over speed, and is expected to consider multiple lines, when making break decisions. Otherwise equivalent to auto”.
TAG review of the feature requested that implementers use at least two heuristics, “to avoid authors using it as a proxy for a more specific thing” <https://github.com/w3ctag/design-reviews/issues/864#issuecom...>.
For total clarity: ‘pretty’ is not necessarily any different from ‘auto’, and ‘auto’ is permitted to do exactly the same thing as ‘pretty’ does, and I hope and expect that browser makers will eventually go that direction for most contexts (contenteditable/ being the main exception, and maybe lower-powered platforms). If you explicitly want a greedy/first-fit technique, use `text-wrap: stable`. Firefox has had a bug open for 13 years where shifting in this direction and using Knuth–Plass almost everywhere has been seriously contemplated <<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=630181" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=630181</a>>, long before text-wrap-style.
-
The `hanging-punctuation property` in CSS
CSS specs are explicitly not interested in prescribing TeX-level control; text-wrap-style is a good example of this: it’s just hints, with the actual algorithms completely UA-defined. And in fact, they’re going out of their way to recommend including multiple distinct heuristics of prettiness, so that developers don’t use it as a proxy for just one thing and start relying on something that is explicitly and deliberately undefined. <https://github.com/w3ctag/design-reviews/issues/864#issuecom...> (And Chromium has done just this: <https://bugs.chromium.org/p/chromium/issues/detail?id=143279...>.)
In other words: you’ve already lost!
-
Microsoft Broke a Chrome Feature to Promote Its Edge Browser
Since people seemed to believing Google PR at face value here is the w3c position in rejecting the proposal:
The intention of the Topics API is to enable high level interests of web users to be shared with third parties in a privacy-preserving way in order to enable targeted advertising, while also protecting users from unwanted tracking and profiling. The TAG's initial view is that this API does not achieve these goals as specified.
The Topics API as proposed puts the browser in a position of sharing information about the user, derived from their browsing history, with any site that can call the API. This is done in such a way that the user has no fine-grained control over what is revealed, and in what context, or to which parties. It also seems likely that a user would struggle to understand what is even happening; data is gathered and sent behind the scenes, quite opaquely. This goes against the principle of enhancing the user's control, and we believe is not appropriate behaviour for any software purporting to be an agent of a web user.
The responses to the proposal from Webkit and Mozilla highlight the tradeoffs between serving a diverse global population, and adequately protecting the identities of individuals in a given population. Shortcomings on neither side of these tradeoffs are acceptable for web platform technologies.
It's also clear from the positions shared by Mozilla and Webkit that there is a lack of multi-stakeholder support. We remain concerned about fragmentation of the user experience if the Topics API is implemented in a limited number of browsers, and sites that wish to use it prevent access to users of browsers without it (a different scenario from the user having disabled it in settings).
We are particularly concerned by the opportunities for sites to use additional data gathered over time by the Topics API in conjunction with other data gathered about a site visitor, either via other APIs, via out of band means, and/or via existing tracking technologies in place at the same time, such as fingerprinting.
We appreciate the in-depth privacy analyses of the API that have been done so far by Google and by Mozilla. If work on this API is to proceed, it would benefit from further analysis by one or more independant (non-browser engine or adtech) parties.
Further, if the API were both effective and privacy-preserving, it could nonetheless be used to customise content in a discriminatory manner, using stereotypes, inferences or assumptions based on the topics revealed (eg. a topic could be used - accurately or not - to infer a protected characteristic, which is thereby used in selecting an advert to show). Relatedly, there is no binary assessment that can be made over whether a topic is "sensitive" or not. This can vary depending on context, the circumstances of the person it relates to, as well as change over time for the same person.
Giving the web user access to browser settings to configure which topics can be observed and sent, and from/to which parties, would be a necessary addition to an API such as this, and go some way towards restoring agency of the user, but is by no means sufficient. People can become vulnerable in ways they do not expect, and without notice. People cannot be expected to have a full understanding of every possible topic in the taxonomy as it relates to their personal circumstances, nor of the immediate or knock-on effects of sharing this data with sites and advertisers, and nor can they be expected to continually revise their browser settings as their personal or global circumstances change.
A portion of topics returned by the API are proposed to be randomised, in part to enable plausible deniability of the results. The usefulness of this mitigation may be limited in practice; an individual who wants to explain away an inappropriate ad served on a shared computer cannot be expected to understand the low level workings of a specific browser API in a contentious, dangerous or embarrassing situation (assuming a general cultural awareness of the idea of targeted ads being served based on your online activities or even being "listened to" by your devices, which does not exist everywhere, but is certainly pervasive in some places/communities).
While we appreciate the efforts that have gone into this proposal aiming to iteratively improve the privacy-preserving possibilities of targeted advertising, ultimately it falls short. In summary, the proposed API appears to maintain the status quo of inappropriate surveillence on the web, and we do not want to see it proceed further.
https://github.com/w3ctag/design-reviews/issues/726#issuecom...
-
Shoelace: A Web Component Kit
Ah, I didn't realize this wasn't solved -- a quick search turns up:
- https://github.com/WICG/webcomponents/issues/788
- https://github.com/w3c/DOM-Parsing/issues/58
- https://github.com/w3ctag/design-reviews/issues/494
- https://web.dev/declarative-shadow-dom
In pre-render they seem to have started in this direction extremely recently:
https://github.com/prerender/prerender/pull/731/files
I don't use prerender so I can't definitively speak to it being solved and hiccup-free, but I think that limitation is going to go away in the future.
-
It's always been you, Canvas2D
There was a ton of work across browser vendors to make this a part of spec:
https://html.spec.whatwg.org/multipage/canvas.html#the-canva...
It's all there. It's all official. That github page was just one part of reaching consensus. There's also TAG review:
https://github.com/w3ctag/design-reviews/issues/627
FWIW Mozilla and Safari signed off on all of these changes at some point in time somewhere, hence why it's allowed to be part of spec. There were some changes that were not allowed to be part of the new API because one of those two said no (like perspective transforms, conic curves).
-
Chromium: Permit blocking of view-source: with URLBlocklist
I would like to quote from the W3C TAG comments on the Managed Device Web API:
https://github.com/w3ctag/design-reviews/issues/606#issuecom...
> > "NOTE: [RFC7258] treats pervasive monitoring as an attack, but it doesn’t apply to managed devices."
> We don't think this is adequate. Given the power dynamics at play in an employer-employee relationship, the UA should still be working in the best interests of the end-user (the employee) even if the device being used is managed by an administrator. That is to say, pervasive monitoring is never a feature.
Chrome may not consider it part of the "web-exposed platform", since the code doesn't live in blink/, but the same logic applies to view-source. The needs of the users are more important than the security theatre you wish to put on for their teacher's benefit.
-
It’s time to ditch Chrome
One case directly related to Chrome browser, and sending data to Google, there is issue with tracking headers. [source](https://github.com/w3ctag/design-reviews/issues/467#issuecomment-581944600)This allows tracking specific Chrome instance among all Google services.We cannot say whether this is used for tracking, but it allows it for sure.\[Register article about the same matter.\]([https://forums.theregister.com/forum/all/2020/02/05/google\_chrome\_id\_numbers/](https://forums.theregister.com/forum/all/2020/02/05/google_chrome_id_numbers/))
- Tag Kills FirstParty Sets Proposal
What are some alternatives?
Mastodon - Your self-hosted, globally interconnected microblogging community
Firefox-UI-Fix - 🦊 I respect proton UI and aim to improve it.
logseq - A local-first, non-linear, outliner notebook for organizing and sharing your personal knowledge base. Use it to organize your todo list, to write your journals, or to record your unique life.
uBlock - uBlock Origin - An efficient blocker for Chromium and Firefox. Fast and lean.
orbitdb - Peer-to-Peer Databases for the Decentralized Web
BezierInfo-2 - The development repo for the Primer on Bézier curves, https://pomax.github.io/bezierinfo
Peergos - A p2p, secure file storage, social network and application protocol
Bitwarden - The core infrastructure backend (API, database, Docker, etc).
kanidm - Kanidm: A simple, secure and fast identity management platform
ungoogled-chromium - Google Chromium, sans integration with Google
Nullboard - Nullboard is a minimalist kanban board, focused on compactness and readability.
webcomponents - Web Components specifications