@itsfoss@protonprivacy I'm pretty hesitant about al the companies integrating AI tooling, but this makes sense to me: > We realised that irrespective of whether or not Proton builds AI tools, users are going to use AI, often with significant privacy consequences. > Rather than have users copying their sensitive communications into third-party AI tools that often have appalling privacy practices, it would be better to instead build privacy-first AI tools directly into Proton Mail.
The biggest thing pushing me away from #ActivityPub is that I want a content replication system, similar to #ipfs : - I want an efficient way to serve content to the global network and save that content offline without losing signatures of authenticity. - I want all the data hosted by one client/server to be transparently loadable by any other client/server with permission. - I want clients to be able to connect to each-other, without servers. 1/3
@silverpill@smallcircles If #activitypub supports everything that we need, it should be trivial to layer it on top of this protocol, possibly built-in, without needing a separate server/bridge.
But I want to build the smallest thing I need first.
I want to avoid tying myself to a protocol that has been, as far as all common implementations are concerned, implemented with different goals and trade-offs in mind.
As far as our testing and experimentation now, the more focused the better.
@silverpill@smallcircles That said, interoperability with ActivityPub is something we are very interested in.
I think there is a lot of opportunity for 2-way communication between ActivityPub and our data model.
---
Just for reference, this post might serve as a useful background for some of the ideas we're considering. Note that this was written before the idea of using an Entity-Component model:
@silverpill@smallcircles I talked to some more ActivityPub savvy colleagues and it does look like you could technically accomplish lots of our goals with ActivityPub, if combined with Iroh for storage.
But ActivityPub is also largely underspecified, and would require extensions that many AP servers don't support.
We prefer to make a very precise protocol specification to give tight interoperability at it's core, but allow component data and schemas to develop independently for extension.
@silverpill Yeah, we're quite familiar with ActivityPub.
There are lots of things that go into it not being sufficient for what we're imagining, but one of the most basic limitations is that when you use actual URLs for entities, you are dependent on DNS and servers, which defeats many local-first use-cases.
Thoughts on making a "Web of Data" instead of a "Web of Pages", and how that might let us take a step away from the dominance of large, complicated browsers.
Self-taught software engineer and problem solver with a passion for producing high quality solutions to real-world problems. I strive to make great things that people can use and enjoy, all to the glory of God.