I need somebody smarter than me to explain this.afaict #ATproto is built on this central database thingy "didplc" that I know they plan to outsource to a non profit.
General Discussion
9
Posts
4
Posters
49
Views
-
I need somebody smarter than me to explain this.
afaict #ATproto is built on this central database thingy "didplc" that I know they plan to outsource to a non profit. better but still a problem imo cause non profits can be evil (or just plain dumb) too.
so how does #ActivityPub avoid a centralization problem like this and what are the tradeoffs in the different models?
-
I need somebody smarter than me to explain this.
afaict #ATproto is built on this central database thingy "didplc" that I know they plan to outsource to a non profit. better but still a problem imo cause non profits can be evil (or just plain dumb) too.
so how does #ActivityPub avoid a centralization problem like this and what are the tradeoffs in the different models?
@wjmaggos ActivityPub has a similar problem, but instead of centralized
did:plcthingy it relies on Domain Name System. -
@wjmaggos ActivityPub has a similar problem, but instead of centralized
did:plcthingy it relies on Domain Name System.gotcha. true. but if there's DNS trouble, the whole web is fucked. probably makes sense to build off that. or maybe somehow if the did:plc ends up making more sense, get the same entity that manages DNS to manage it.
but what are the tradeoffs in these models?
-
gotcha. true. but if there's DNS trouble, the whole web is fucked. probably makes sense to build off that. or maybe somehow if the did:plc ends up making more sense, get the same entity that manages DNS to manage it.
but what are the tradeoffs in these models?
@wjmaggos
In DNS, there is only one root authority (it's not that simple in reality, but for the sake of this comparison let's say there is only one). The advantage of using DIDs is that there could be many root authorities. In fact, anyone could be a root authority. Another advantage is various interesting cryptographic tricks that DIDs enable. But DIDs are very new in comparison to DNS, and there is almost no infrastructure to build upon -- that's the main downside.However, ATProto doesn't really make use of "D" in DIDs. Both
did:plcanddid:webare not decentralized. -
@wjmaggos
In DNS, there is only one root authority (it's not that simple in reality, but for the sake of this comparison let's say there is only one). The advantage of using DIDs is that there could be many root authorities. In fact, anyone could be a root authority. Another advantage is various interesting cryptographic tricks that DIDs enable. But DIDs are very new in comparison to DNS, and there is almost no infrastructure to build upon -- that's the main downside.However, ATProto doesn't really make use of "D" in DIDs. Both
did:plcanddid:webare not decentralized.One thing I will add is —
Internet domains have been seized before.
(There is at least one book documenting for some of the history of it. But, it keeps on happening.)
...
This is an additional problem to people losing their Interent domains due to not continuing to pay the yearly rent for it.
-
One thing I will add is —
Internet domains have been seized before.
(There is at least one book documenting for some of the history of it. But, it keeps on happening.)
...
This is an additional problem to people losing their Interent domains due to not continuing to pay the yearly rent for it.
@reiver @silverpill @wjmaggos the web and email depend on DNS.
-
@reiver @silverpill @wjmaggos the web and email depend on DNS.
@reiver @silverpill @wjmaggos it is the most successful, global, distributed identity system that humans have ever created. More than postal addresses; more than phone numbers. Probably second only to the use of personal names.
-
@reiver @silverpill @wjmaggos it is the most successful, global, distributed identity system that humans have ever created. More than postal addresses; more than phone numbers. Probably second only to the use of personal names.
@reiver @silverpill @wjmaggos domain names are instantly recognizable. Almost anyone can get one. There is an amazing toolset for obtaining and managing them.
-
@reiver @silverpill @wjmaggos domain names are instantly recognizable. Almost anyone can get one. There is an amazing toolset for obtaining and managing them.
@reiver @silverpill @wjmaggos we have spent 40 years educating internet users about how domain names work. They know how email federation works; they know how web federation works. They know what it means to own your own domain and to use someone else's domain.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@benjohn it's not a peer to peer protocol. It's federated - meaning you can pick a provider - like email or the Fediverse.
-
@daniel I was just checking out the Wikipedia page, thanks for the pointer. … does it work well peer to peer? Identifies seem to be tied to a domain?
-
@daniel@gultsch.social absolutely, the same naive expectations happen often when people think forums are easy to build :smile:
@pixelschubsi@troet.cafe is definitely on to something about re-using an existing XMPP server in order to avoid the heavy lift. The less the maintenance burden for me, the better as far as I'm concerned.
-
@julian @pixelschubsi I understand the instinct of wanting to reuse the parts you already have. Protocol parsing, identities, profiles etc. However those will very quickly become extremely minor building blocks in the complexity of instant messaging.
It's very easy to underestimate the scope and feature creep of IM. I've seen this happening in other places where people initially think that IM is just passing some messages around. And then users demand more features and then you reinvent XMPP.
-
@julian @daniel so in practice it would probably be the other way round: that heavy lifting you're rightfully afraid of has already been done and even the large tail of the remaining 20% (that in reality need 80% of the effort) are largely done.
If we were to agree to go the XMPP route, we could have fully-featuered deployment-ready implementations of instant messaging on top of AP identities in weeks to months. If it's something entirely new on top of AP, it's going to take years.
-
@julian @daniel I'm looking at it from a different perspective. IMO the Mastodon server (as an example) doesn't need to implement XMPP itself (it could, but it doesn't need to). Just like it doesn't implement HTTP itself.
It could instead rely on existing implementations. Take an existing XMPP server, reverse proxy its websocket endpoint, use the existing Mastodon auth to sign in, and embed an existing XMPP web client in the web frontend.
-
@silverpill @pixelschubsi @tris you can have a single account (or as I phrased it 'identity and login credentials') across different protocols.
For example your Google account works across multiple protocols. And even in the federated world we have several cases where email address == xmpp address.
So to repeat myself: using the same identity is good. Doesn't mean you are locked into ActivityPub if you want to build instant messaging.
-
To preface — I'm in agreement that ActivityPub probably isn't the best protocol to use for instant messaging. There's a lot of FUD still being spread about XMPP and I am outside of most of those discussions. NodeBB only supports AP at current.
That said, there's interest in pursuing AP as a delivery protocol for instant messaging because integrating a separate protocol is a heavy lift for everybody involved. It's a heavy lift if you already support AP, and it's a heavy lift when you support no federating protocols at all. Imagine a site looking to federate... now they have to use AP+XMPP? AP+Delta? etc...
Setting aside all the existing reasons why AP isn't ideal, I will say this... It clears the baseline expectations:
Messages can get sent via AP :heavy_check_mark: Messages can be privately addressed via existing AP addressing mechanisms :heavy_check_mark:That's it. The rest is icing. Really important icing, but for 99% of conversations, icing.
