decided to look into #solid (the Tim Berners-Lee related one) and, why the hell isn't it in everything by now, or at least able to be?!
Like, why can't I have my files on a Solid pod show up in Nautilus yet?!
In particular, I think it might be really great for a "metaverse passport," a common ID that would include a display name and avatars, and you could potentially use Solid's existent profile and friends stuff too.
> [HTMX] can get you 80% there with radically less complexity. No extra dependencies, no build step, no advanced tooling (now re-written in Rust!), no complicated state management, no “double data” problem, no hydration mismatch… Just write your HTTP server and return HTML!
"#ActivityPods is a combination of two #W3C standards: #ActivityPub, and the #Solid specification. The first standard is for data federation and networks, the second is for data storage and access. The ideals of both projects put together create a compelling vision: data control, across user applications, in service to communication across the web."
The #ActivityPub ecosystem is evolving at a rapid pace. One project, #ActivityPods, is making an ambitious effort to combine the Fediverse with the power of #Solid.
Gave an improptu summary of the UBOS project and architecture and key differences at #IIW today in a session on Personal Data Stores. Others talked about #solid, #tbd/decentralized web nodes and more.
Messing around with #ActivityPods at work. Question: does the mypod.store provider only work with the three installed Solid apps? (Mastopod, Mutual Aid, Welcome To My Place)
I can't seem to get other #Solid apps to work with it, unless I'm misunderstanding something? I thought ActivityPods was intended to run on top of standard Solid Pods.
#Decentralization#Privacy#DataProtection#Solid: ""From the beginning, I always meant for the web to be a platform for creativity and collaboration," says Sir Tim Berners-Lee, inventor of the world wide web.
"The first decade of the web lived up to that promise, but that's not what we've seen in the last 20 years or so."
Sir Tim says a particular problem is the way personal data is handled. When you log in and store data in a website, it can only be used within that website.
But an open source software project, called Solid, is designed to reverse that situation.
The idea of Solid is that people have a private data store, and they get to choose which organisations can access it, for what purpose, and for how long.
Called a Personal Online Data Store, or Pod, it gives users control over their data, and the freedom to combine it or share it between applications.
Sir Tim is co-founder of Inrupt, a company that provides Solid-based technologies. He says using the technology would mean that data storage would be "centred around people, instead of around apps".
Have been looking at #dat again, do you think we can build this:
The Open Media Network is a trust based, human moderated, #4opens project that builds a database shared across many peers (both #p2p and server). The project is more important for what it DOES NOT DO, than what it does do, using technology to build human networks. There are ONLY 5 main functions:
• Publish (object to a stream of objects) – to publish an object (text, image, link)
• Subscribe (to a stream of objects) – to a person or organization, a page, a group, a hashtag subject etc.
• Moderate (stream or object) – you can say I like/dislike (push/pull or yes/no) this etc you can comment.
• Rollback (stream) – you can remove from your flow (instance database) untrusted historical content by publishing flow/source/tag.
• Edit (meta data of object/stream) – you can edit the metadata in any site/instance/app you have a login on.
We would build in the moderation tools of the #Fediverse.
This is the back-end of the project to build a #DIY trust based, grassroots, semantic web. The front-end may be anything you like, for example regional-/city-/subject-based #indymedia sites to a distributed archiving project #makeinghistory
The data cauldron and the golden ladle. The technology we call the #WitchesCaldron.
@witchescauldron Another platform to consider is #SafeNetwork which is coming together right now. (For example, I'm looking into porting my earlier proof of concept for a an LDP interface (#LinkedData / #RDF) to the new API, and then some #Solid apps.)
I think what you propose would be feasible, certainly worth looking into because the platform has some unique characteristics and I think now would be the perfect time to start building for it. Fully autonomous #p2p#e2e#security.
We Distribute is a CC-licensed open media project. It serves as a people-focused tech publication, with the goal of informing and educating people about three things:
Decentralized Communications
User empowerment
The future of the Internet
Most of what we do involves reporting on the day-to-day developments of the #Fediverse. In fact, our articles are ActivityPub-enabled, and integrate directly into the network.
However, the Social Web / Decentralized Social movement involves far more efforts and technologies that we think are also worth reporting on: #Matrix, #XMPP, #Bluesky, #Nostr, #SecureScuttlebutt, and #Solid all bring interesting pieces to the puzzle.
Our ultimate goal is to showcase the ongoing efforts to change the shape and form of the Internet itself, at a grassroots level. Join us on this exciting journey. #WeDistribute
All the FEPs are very interesting as simple ways to extend ActivityPub. I'm also naturally very interested by any subject around the interoperability between #ActivityPub and #Solid (as #ActivityPods developer). I'm also interested about how to use ActivityPub to bring Open #Badges to a social dimension (see this other project I've been contributing to: https://activitybadges.org)
I've a bit more to do on #vdash which has given me more time to wonder about what next.
As #SafeNetwork is getting pretty exciting r.n. I'm veering towards something to help Devs with #p2p apps, and feeling a buzz around compiling the client API for #WASM, and showing how to build native cross platform mobile and desktop apps using your web framework of choice (eg #SveltKit), #Rust/WASM and #Tauri.
Then an LDP containers API so existing #Solid apps become Safe Apps in this setup. #LinkedData
so we have been batting around the idea of some kinda paper bot for awhile re: the question "how do we track discussions around scholarly work" and I am starting to think this paper-feeds project is the way to do it.
So say it is an AP instance and it has one primary bot user, you follow it and it follows you back. When you make a post with something that resolves to a DOI, then that post is linked to that work. Any hashtags used in that post are added to that papers keywords (assuming some basic moderation and word ban lists). Then keyword feeds are also represented as AP actors that can be followed and make a post per paper. I wonder if we can spoof the "in reply to" field to present all those posts as being replies to that paper.
So say the bot also has some simple microsyntax for linking your account to an ORCID - either directly in a profile field, or by @'ing the bot and checking a rel=me, or hell even oauth. Then you could also relate when the authors of given works talk about other works and use that as another proximity measure. Then you could make an author RSS feed/AP actor that is just the works someone publishes and optionally that they talk mention - so eg I could make an aggregate feed for the papers my friends are reading.
Then you could have instances of this feed generator follow one another and broadcast aggregated similarity information at a paper level not linked to personal information, and also opt-in info like the fedi account <-> ORCID link. Since youre on AP already you basically get that for free.
Thinking about what would be useful for social discovery of scholarly works, and there are a lot of really interesting ideas once you start actually yno doing it starting from a place of not having a product to sell or a platform to run so you avoid some of the scale and liability probs.
@hochstenbach yes yes - i have ultimately come to the conclusion that the LDP needs to be #P2P in order for it to do the things it wants to do. Fluid ontologies indexed by DNS have basically never worked, and so most of RDF world just treats them like non-dereferencing IRIs, which is sad - it's just intrinsically fragile, and really the only #LinkedData vocabularies you can really rely on still being there are the ones that w3c hosts because they're the only ones that really care about URLs staying the same forever.
I really like the design of what you're working on here - just operating on files is great, rules syntax took a bit to read but makes sense and seems amenable to interface design, and i especially like the plugin approach to 'just pull and push from anywhere'. The problem i have with thinking about the longevity or deployability of things like this are not really intrinsic to your project at all, but about the imo naive assumptions that LD makes about DNS: it is genuinely expensive and complicated to put something on the 'net for your average bear (timbl said as much). All the (necessary) placeholder example.com's in the demos are a reflection of that - since of course the rule isn't actually at example.com, presumably it isn't actually dereferencing there, and so it becomes just an IRI slug that is simultaneously necessarily bound to a URL but can't use it.
my longest lasting question in studying LD is "where is #SOLID?" I have tried and failed dozens of times to just run something from the project and have never managed to do it and have never heard of someone actually using it day-to-day. millions of people run bittorrent clients though, so it's not just an intrinsic "people don't want to run software" problem. The barrier to 'how do i actually put my stuff online' has to be a lot lower than 'rent a domain, manage a bunch of paths, and run an always-on server forever'.
The federated approach like the fedi and eg. institutions hosting pods is promising for many things, but it is sort of a nonstarter for anything with arbitrary clearweb user-generated content for liability and security reasons, so I think that would be super dope for things like notifications for scholarly work, but I think institutions will balk at an eventing framework that requires arbitrary code to run on an institutionally managed server, and especially can result in arbitrary content being available on their domain.
I think we should take advantage of existing infrastructure though - eg. i like how you're using npm to host and version vocabularies, and that federated infrastructure could (and imo should) serve some backstop role of preserving availability and providing bootstrap entrypoints for a p2p swarm. I think that has to look like using different protocols than HTTP though, and following along that line you pretty rapidly get to needing social infrastructure at the base in order to have comprehensible namespacing (rather than a bunch of long hashes, even with some naming system patched over the top of it, as IPNS demonstrates doesn't really work that well). I think your going towards integration with email and masto and whatnot from a local client is a nice set of steps towards personal web tooling, and i'm gonna keep this bookmarked for when i get closer to working on something related :)
@jonny
FYI I worked with the help of the #Solid community including Timbl, to demonstrate that the Solid protocol, or at least a useful subset could be implemented and used on a #p2p data and comms network.
I believe the issues with centralised DNS and server based hosting (self hosting included) are not sufficient to meet the goals of Solid which include decentralization and self ownership of data.
I was able to run existing Solid apps running on p2p #SafeNetwork.
This is fascinating to see.. I have long been intrigued by the ideas around #SOLID “pods” from Tim Berners-Lee and others working with him. The whole idea of keeping all your data in one place, and then having services pull it from your cache. Very much aligned with the #POSSE philosophy for publishing.
But there has not yet been many ways to use those pods. Could this combination with #ActivityPub help? Hmmm… glad to see people working on this!
@danyork@box464 Yeah, I was excited by SOLID, but disappointed at the lack of concrete progress and the lack of interop with other technologies.
ActivityPods solves some of those issues. I'd prefer to self-host, but I'm reticent to self-host a docker application. Also I'd prefer to store media in cloud storage I'm already paying for.
So, for now, I'm self-hosting a tiny ActivityPub server and storing media in cloud storage. Is that a SOLID pod of sorts?