Can I build a blockchain on top of it?
ActivityPub: decentralized social networking protocol
41–50 of 140 posts
Re: ActivityPub: decentralized social networking protocol
#42Earlier quoted context omitted.
AFAIK XMPP is more geared towards IM than microblogging and it's very complex and difficult to get right due to many extensions.
Actually, I never did any XMPP coding but from what I belief it is more difficult to get it 'complete' then to get it 'right'. I mean you get it 'right' even with a minimal/core implementation but 'complete' only with about the 50 most common extensions. Getting it 'right' seems to be a problem when the XEP definition is open to interpretation. Nevertheless, I agree that it would not fit the XMPP ecosystem to be used…
Check out Movim for an example: https://movim.eu/
Re: ActivityPub: decentralized social networking protocol
#43From my quick read of the spec, server-to-server federation assumes that servers can be trusted. That need not be the case; unless a message is signed it should not be assumed to have come from a specific user. I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). The other question is whether we want server-to-server federatio…
Re: ActivityPub: decentralized social networking protocol
#44I have been in touch with Tim Berners-Lee and his Solid project since late 2016. Since then, I've run across many people who work at W3C and in the protocol space, and it's inspired me to open up and publish protocols derived from our platform (eg https://github.com/Qbix/auth ) But I believe that, in the end of the day, mass adoption can only be done when there is a popular platform. Whether it's closed source like F…
Re: ActivityPub: decentralized social networking protocol
#45Earlier quoted context omitted.
AFAIK XMPP is more geared towards IM than microblogging and it's very complex and difficult to get right due to many extensions.
Actually, I never did any XMPP coding but from what I belief it is more difficult to get it 'complete' then to get it 'right'. I mean you get it 'right' even with a minimal/core implementation but 'complete' only with about the 50 most common extensions. Getting it 'right' seems to be a problem when the XEP definition is open to interpretation. Nevertheless, I agree that it would not fit the XMPP ecosystem to be used…
I don't think there is a point in getting it complete. You choose the XEPs you want by looking at what your client/server goals are. Also if you need help in choosing, there are pointer XEPs, like the Compliance Suites, or the mailing list, or the chatrooms. See https://xmpp.org/community/
> Getting it 'right' seems to be a problem when the XEP definition is open to interpretation.
When in doubt, ask the author/council.
Re: ActivityPub: decentralized social networking protocol
#46From my quick read of the spec, server-to-server federation assumes that servers can be trusted. That need not be the case; unless a message is signed it should not be assumed to have come from a specific user. I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). The other question is whether we want server-to-server federatio…
> I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). This is exactly what namecoin tried to solve. Buy an identifier, put whatever you want in it. Example: https://nameid.org/?name=rakoo > The other question is whether we want server-to-server federation at all instead of a P2P network like bittorrent. We want something in b…
The only issue is client support and the fact that I don't have a good sense of the state of development/stability/soundness for SSB.
If you (or anyone) has experience actually using SSB or similar true P2P platforms, I'd be very interested to hear what did or didn't work well.
Re: ActivityPub: decentralized social networking protocol
#47From my quick read of the spec, server-to-server federation assumes that servers can be trusted. That need not be the case; unless a message is signed it should not be assumed to have come from a specific user. I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). The other question is whether we want server-to-server federatio…
Re: ActivityPub: decentralized social networking protocol
#48ELI5 ActivityPub vs xmpp semantics
AFAIK XMPP is more geared towards IM than microblogging and it's very complex and difficult to get right due to many extensions.
For the record I'm the main developer of a XMPP based "social network" project (Salut à Toi), and we are able to communicate natively with others XMPP projects (e.g. Movim) for years (we can share comments like in the video, it's the basis of common standard).
The "many extensions" thing is commonly misunderstood by non XMPP people thinking that it's making software more complicated or hard to maintain. But it's not true: extensions is a strength of XMPP allowing to concentrate on one feature at a time, evolve it, change it if needed, and there is a very good negotiation mechanism. Software are evolving, and it's normal that different clients/servers have different feature, but even with that they can still communicate together. The case is common actually: the websites on your browser can test for implemented features in javascript for instance before activating this or that.
XMPP is not a single technology but a base to support many coherent technologies, for many different use cases.
To go back to this ActivityPub, while I'm a bit annoyed that nobody tried to contact us to join our efforts on XMPP, resulting in yet another standard, at least if it's followed by some platforms, it may simplify the creation of gateways. I've looked at the specs, I don't think that putting "like", and "followers" as the main feature of a social network is a good idea. At first sight, it doesn't seem too difficult to translate to XMPP.
Re: ActivityPub: decentralized social networking protocol
#49Earlier quoted context omitted.
In OStatus 'salmons' are messages sent from one server to another that contain posts. They are signed, so the receiving server knows if it can trust it. If person peter@example.com mentions bob@differentsite.org, a salmon is sent from example.com to differentsite.org containing the message. The endpoint that this is posted to is the 'salmon endpoint'. Using a second endpoint for privacy enhanced messages would have t…
Oh that's nice, thanks for the explanation. I'm currently working on a social network and I like the idea of being able to connect with other ones via open standards. I need to do more research on implementation.
Re: ActivityPub: decentralized social networking protocol
#50I have been in touch with Tim Berners-Lee and his Solid project since late 2016. Since then, I've run across many people who work at W3C and in the protocol space, and it's inspired me to open up and publish protocols derived from our platform (eg https://github.com/Qbix/auth ) But I believe that, in the end of the day, mass adoption can only be done when there is a popular platform. Whether it's closed source like F…
If we didn't have these restrictions, this would be a purely academic debate, because there are already many practical ways to extract information from a resource and transmit it to other computers.
"Federation protocols" are a way of volunteering this information in a common language, but there's no real technical reason that's necessary to get "decentralized social media" or other such things. They're only considered potential solutions because effective scraping is not allowed.
Decentralized / democratized information access is not an issue that can be solved technically. It needs to be solved socially (primarily because the necessary technical infrastructure already exists, and is just held back by legal anti-solutions).