Hacker News Reader

Comment by pmlnr | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

Fair and important questions. The closest immediate answer I have is https://indieweb.org/SWAT0 but the page is quite dense with indieweb terms.

EDIT: 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.

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.

There's a list of features documented for :

https://indieweb.org/Facebook#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.

Your example works with those protocolls already too and I implemented it on my website, here is a example: 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%2...

Yup, I'd rather see an abstraction extracted from a solid system than created eagerly. There may be a first mover advantage to the "winner", but it's better than attempting to conform to a mostly unused protocol only to find each app adds on to it in their own ways because their feature set is larger than the protocol.

I see no way of controlling privacy in a decentralized system. It'd be like trying to delete all the emails you've sent to other people or stop someone from forwarding an email. Once you put the data out there in a decentralized system, it's out there permanently. Centralization allows for some control.

This is a big problem I think as well. Do we really want a social network where nothing can be deleted? I have used a few and it definitely makes me think before posting.

Here's a question I genuinely don't know the answer to: is there a standard format or file format for requirements and motivational modelling? I feel like now would be the PERFECT time for a collaborative Archimate 3.0 motivation model design, but I know of exactly zero tools that could do this remotely and at scale.

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-.

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.

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.

> 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

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.

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

Reply on news.ycombinator.com