Currently pronto is tied to galacteek but it wouldnāt be too much work to make it into a separate, standalone service (in python or other languages). The thing is, the whole linked-data machinery is a bit complex and iād like to test it on a larger scale first.
Each node exposes their RDF graphs via an IPFS P2P SparQL service (P2P stream). Periodic pubsub messages trigger the sync process: new ontolochains are retrieved via SparQL, and then each chain is synced (pull new records, and for each record do the expansion and graph it).
Because of the combination of pubsub + P2P SparQL, each node knows everything at the same time (Hashgraph has similar properties).
Where can I find a link to the defluencer spec so I can start PubSubbing to it? The spec I wrote was just a mere suggestion:
All it really does is suggest we can just publish PublicKeys/CID pairs. My idea was to listen to all pubsub events on a channel and discard ones not sent by PKs I āfollowā (or like). I considered one requirement to be āzero barrier to entryā meaning that anyone can get started writing a client for in a couple of hours, just basically building on nothing more than one of the IPFS PubSub examples.
So yeah if thereās already a working spec for how to do Social Media-like messaging over IPFS PubSub Iām onboard. Unless itās ugly or complex, Iāll join you, and add your protocol to Quanta in a heartbeat.
Ah I misunderstood what you said @wclayf !
My protocol does not have ONE pubsub topic but many per person and you sub to the person you want.
Could one topic scale to planet size? IDK! Seams like a lot of filtering to do the more popular it gets.
Let me explain how my stuff work, you might like it. (or notā¦)
A beacon object has all the data to sub and access a person content, pubsub topics, IPNS links, etcā¦ This beacon doesnāt change and itās CID can be used as a social media ID.
Interesting. Do you know if anyone has tried getting Linked Data Fragments (LDF) working over IPFS? Seems like it should be fairly easy to do.
Iāve also been thinking that IPNS urls are a much better publishing mechanism for RDF than http. It solves the stupid http-range-14 issue because the dereference is built in to the protocol and you donāt have to depend on controlling a domain name which was a bad decision to rely on everyone having access to a domain name. Purls where a bandaid. I would trust the persistence of a private cryptographic key way more than the ownership over a domain name.
I know a bit about LDF, i donāt know if someone does this on IPFS. LDFlex and comunica are really cool, Solid uses that.
Yes, a top priority was to control the schemas via IPNS, as i donāt trust DNS (who should ā¦). The schemas live on your node, are easy to upgrade and manage ā¦
So this guy (project link below) implemented what I was calling IPSMā¦over the weekend!!! Two days! Heās some kind of super genius and Iām not even kidding.
You guys should check that project out. I spent all day looking it over, studying it, running it, and it works!! Itās a Social Media network in pure IPFS and is as simple as the IPSM proposal/blog I wrote. And it ājust works ā¢ā
@SionoiS Iāll look over ābeaconā also, because that sounds pretty advanced/complex, but Iām glad @undyingwraith showed that itās possible to have a sort of āLevel 1 Complianceā of IPSM (meaning purely simple IPFS PubSub-based messaging), using PublicKey only as identityā¦
ā¦and he just so happened to do this with my favorite tech stack: TypeScript+React. He nailed it.
The dvoz dapp is now a bit faster when it comes to making SparQL queries on the pronto RDF graphs, syncing between nodes should be less cpu-intensive now.
Some people might try to visit IPSM using the ipfs facility integrated into Brave Browser. Could you please include instructions for how to adjust the necessary settings in Braveās ipfs or ipfs-companion? (If you could add some screenshots or even create a video gif, maybe using sharex or something similar, that would be great!)
Brave having IPFS integrated is awesome BUT itās very hard to configure it without fucking up (and if you do, IPFS in brave will no longer work at all yikes!).
Itās sad but until they fix it somehow Iām not going that route.
Consider that many of the most popular Social Media platforms are mobile-first.
Nearly all of them are entirely catered to the phone app, while apps like Tiktok only really have a website for viewing, whereas Snapchat doesnāt allow you to access the platform AT ALL without the mobile app.
So I think having the user install IPFS is a non-issueājust bundle a node with your application, optimize it for mobile, and have a web2.0 website meant purely for non-users to discover the app or read public-facing content.
