5 ms·

This is yet another platform solution. The problem with platform solutions is that they still present one and only one choice of software. Decentralized system

by pmlnr 9y ago

This is yet another platform solution. The problem with platform solutions is that they still present one and only one choice of software. Decentralized systems can only take off if they are built around standardized protocols - this is why email works. The choice of smtp servers to run, email clients to choose from, that's what's making it resilient. Ideas like ActivityPub, webmentions, microsub, micropub, while not strictly protocols - all on top of HTTP - could allow us to build real decentralisation, with the weapon of choice on platform, language, client - this is what's truly needed. Most of the platforms like Diaspora, Friendica, Mastodon, can, could, or already have adopted some of these, thus making a good step towards true federation, when anything can talk to anything. EDIT ... but the emphasis right now should be on the glue, the protocols connecting them, not just only the software implementing it.

MarceColl 9y ago
While I agree that the emphasis should be on the protocols traction is important and most people see the platform. It can also show some deficiencies of the protocols which is always good. I think most of these platforms do understand the need for true federation. For example Mastodon can now talk and interact with PeerTube through ActivityPub, GNU Social and Mastodon can completely interoperate too.
- pmlnr 9y ago
  I'm deeply aware how important UX and the actual interfaces are; however, there are still some underdeveloped building blocks, which are not getting enough attention. It is true that user interfaces are just as important, but half-baked solutions might do more harm, than good, resulting in disappointment in those who'd be willing to try them out.
  - kitotik 9y ago
    Leading with UX could be a good (the best?) way to both aid adoption by the normal folks AND let a sane set of requirements emerge that steers the solutions to the most desired set of problems. As much as most people on HN would like to have these protocols specified ‘correctly’, this feels like a situation where the perfect is the enemy of the good.
    - pmlnr 9y ago
      No need for perfect at all, see webmentions: it has a lot of room to grow (private mentions, vouch, etc), but in essence, the core is simple to adopt.
amelius 9y ago
Emphasis should be on the requirements. What do we want the system to do? And how can we control our privacy? Let's answer these questions first.
- deleted 9y ago
  [deleted]
- pmlnr 9y ago
  Fair and important questions. The closest immediate answer I have is https://indieweb.org/SWAT0 https://indieweb.org/SWAT0 but the page is quite dense with indieweb terms. EDIT: https://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SWAT0 https://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SW... might be a better source. Defining a minimum set of features for what a social network (media? web? system?) is is certainly a required step, and any suggestions are welcome.
  - amelius 9y ago
    That's a start, but I suspect we're better off thinking about all possible features, because this allows us to define a protocol that generalizes better. In your example, users can be tagged in a photo. That's nice. But let's say that in the future we want to share who's attending what events. Perhaps we can use the same kind of constructs in the protocol for both uses. Of course, an implementation does not need to support all features from the start.
    - pmlnr 9y ago
      There's a list of features documented for : https://indieweb.org/Facebook#Features https://indieweb.org/Facebook#Features https://indieweb.org/Twitter#Features https://indieweb.org/Twitter#Features However, I don't think there's any kind of standard-ish list for what's a minimum feature set for a social network. Please feel free to add one to the indieweb wiki, as any help is welcome.
    - jeena 9y ago
      Your example works with those protocolls already too and I implemented it on my website, here is a example: https://jeena.net/events/11 https://jeena.net/events/11 And you can get all of that machine readable too: http://pin13.net/mf2/?url=https%3A%2F%2Fjeena.net%2Fevents%2F11 http://pin13.net/mf2/?url=https%3A%2F%2Fjeena.net%2Fevents%2...
samirillian 9y ago
It says it uses free software and free protocols? Wonder what that means.
toyg 9y ago
That's what Movim does, by building on XMPP and its extensions. It's still pretty rough though, and administering a node (something that regular users are NOT required to do, but I thought it would be cool) requires some knowledge of XMPP/ejabberd (which I lack, as I discovered). Ideally I'd be happy with something like that, where a single geek can provide a secure and federated social hub to his circle of friends/family.
- pmlnr 9y ago
  I tried to run movim many years ago, but failed; rough was mere raw around 2012. I still very much like the idea of movim, but it needs a lot of work.
gressquel 9y ago
I have a feeling none of these "decentralized" social networks are going to succeed in capturing the users, but I believe one of these will attract the users for something else than the feature "decentralized". When it happens, whoever owns the site will then move away from the initial concept and build the site around the side-effect feature that attracted the users and then capture the entire audience and thus kill facebook once and for all-.
buovjaga 9y ago
> This is yet another platform solution. The problem with platform solutions is that they still present one and only one choice of software. Friendica supports a ton of protocols, see the "Interoperability" section on the front page. Regarding ActivityPub, it is good to keep in mind the reality: https://github.com/friendica/friendica/issues/4688 https://github.com/friendica/friendica/issues/4688 Quoting MrPetovan: > ActivityPub is a "loose standard", meaning that it doesn't define precisely each interaction. "Supporting ActivityPub" doesn't make any sense, because, per the standard, implementers are forced to make local decisions about how to convey specific features via ActivityPub because of an intended lack of description. > In this context, you can claim "supporting ActivityPub" and not being able to interact with any other service also claiming "supporting ActivityPub" just because you made different implementation decisions. > Another angle: Mastodon implemented ActivityPub for internal communication between Mastodon instances. So they designed their usage of ActivityPub according to their specific usage and features since the standard actually encourages you to do so by leaving parts intentionally vague. However, if any other project wants to communicate with Mastodon instances, they will have to know which specific decisions were made for the intentionally vague parts of the standard because you can't just guess. > It is different from OStatus where interactions were much more precisely defined, so you actually could rely on the standard definition to implement a single connector that would mostly work with most OStatus services because the vague parts were reduced to a minimum.

by pmlnr 9y ago

MarceColl 9y ago

While I agree that the emphasis should be on the protocols traction is important and most people see the platform. It can also show some deficiencies of the protocols which is always good. I think most of these platforms do understand the need for true federation. For example Mastodon can now talk and interact with PeerTube through ActivityPub, GNU Social and Mastodon can completely interoperate too.

pmlnr 9y ago
I'm deeply aware how important UX and the actual interfaces are; however, there are still some underdeveloped building blocks, which are not getting enough attention. It is true that user interfaces are just as important, but half-baked solutions might do more harm, than good, resulting in disappointment in those who'd be willing to try them out.
- kitotik 9y ago
  Leading with UX could be a good (the best?) way to both aid adoption by the normal folks AND let a sane set of requirements emerge that steers the solutions to the most desired set of problems. As much as most people on HN would like to have these protocols specified ‘correctly’, this feels like a situation where the perfect is the enemy of the good.
  - pmlnr 9y ago
    No need for perfect at all, see webmentions: it has a lot of room to grow (private mentions, vouch, etc), but in essence, the core is simple to adopt.

amelius 9y ago

Emphasis should be on the requirements. What do we want the system to do? And how can we control our privacy? Let's answer these questions first.

deleted 9y ago
[deleted]
pmlnr 9y ago
Fair and important questions. The closest immediate answer I have is https://indieweb.org/SWAT0 https://indieweb.org/SWAT0 but the page is quite dense with indieweb terms. EDIT: https://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SWAT0 https://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SW... might be a better source. Defining a minimum set of features for what a social network (media? web? system?) is is certainly a required step, and any suggestions are welcome.
- amelius 9y ago
  That's a start, but I suspect we're better off thinking about all possible features, because this allows us to define a protocol that generalizes better. In your example, users can be tagged in a photo. That's nice. But let's say that in the future we want to share who's attending what events. Perhaps we can use the same kind of constructs in the protocol for both uses. Of course, an implementation does not need to support all features from the start.
  - pmlnr 9y ago
    There's a list of features documented for : https://indieweb.org/Facebook#Features https://indieweb.org/Facebook#Features https://indieweb.org/Twitter#Features https://indieweb.org/Twitter#Features However, I don't think there's any kind of standard-ish list for what's a minimum feature set for a social network. Please feel free to add one to the indieweb wiki, as any help is welcome.
  - jeena 9y ago
    Your example works with those protocolls already too and I implemented it on my website, here is a example: https://jeena.net/events/11 https://jeena.net/events/11 And you can get all of that machine readable too: http://pin13.net/mf2/?url=https%3A%2F%2Fjeena.net%2Fevents%2F11 http://pin13.net/mf2/?url=https%3A%2F%2Fjeena.net%2Fevents%2...

samirillian 9y ago

It says it uses free software and free protocols? Wonder what that means.

toyg 9y ago

That's what Movim does, by building on XMPP and its extensions. It's still pretty rough though, and administering a node (something that regular users are NOT required to do, but I thought it would be cool) requires some knowledge of XMPP/ejabberd (which I lack, as I discovered). Ideally I'd be happy with something like that, where a single geek can provide a secure and federated social hub to his circle of friends/family.

pmlnr 9y ago
I tried to run movim many years ago, but failed; rough was mere raw around 2012. I still very much like the idea of movim, but it needs a lot of work.

gressquel 9y ago

I have a feeling none of these "decentralized" social networks are going to succeed in capturing the users, but I believe one of these will attract the users for something else than the feature "decentralized". When it happens, whoever owns the site will then move away from the initial concept and build the site around the side-effect feature that attracted the users and then capture the entire audience and thus kill facebook once and for all-.

buovjaga 9y ago

> This is yet another platform solution. The problem with platform solutions is that they still present one and only one choice of software. Friendica supports a ton of protocols, see the "Interoperability" section on the front page. Regarding ActivityPub, it is good to keep in mind the reality: https://github.com/friendica/friendica/issues/4688 https://github.com/friendica/friendica/issues/4688 Quoting MrPetovan: > ActivityPub is a "loose standard", meaning that it doesn't define precisely each interaction. "Supporting ActivityPub" doesn't make any sense, because, per the standard, implementers are forced to make local decisions about how to convey specific features via ActivityPub because of an intended lack of description. > In this context, you can claim "supporting ActivityPub" and not being able to interact with any other service also claiming "supporting ActivityPub" just because you made different implementation decisions. > Another angle: Mastodon implemented ActivityPub for internal communication between Mastodon instances. So they designed their usage of ActivityPub according to their specific usage and features since the standard actually encourages you to do so by leaving parts intentionally vague. However, if any other project wants to communicate with Mastodon instances, they will have to know which specific decisions were made for the intentionally vague parts of the standard because you can't just guess. > It is different from OStatus where interactions were much more precisely defined, so you actually could rely on the standard definition to implement a single connector that would mostly work with most OStatus services because the vague parts were reduced to a minimum.