Hacker News new | past | comments | ask | show | jobs | submit login
Plume – WIP Federated Blog Engine with ActivityPub (github.com/plume-org)
157 points by lkurusa on June 27, 2018 | hide | past | favorite | 54 comments



Federation is cool. I have the feeling it needs its "Ubuntu Moment".

Mastodon and Plume are interesting technology wise. But it seems there are no instances with good design yet. I tried hard to like mastodon.social but the interface drives me insane. It's even worse then Twitter.

Until Ubuntu arrived on the scene, Linux was for hardcore nerds. Now every technically interested person has at least tried it.

I wonder what would happen if ActivityPub was used to build Twitter/Instagram/FB alternatives with less aggressive advertising. But with the same user friendly interfaces.

It wouldn't need much. Rather less. For example the choice of fonts and colors on mastodon.social. Who thought it's a good idea to use tiny grey chars on a black background? And then the idea to have multiple feeds on the screen that constantly update without user interaction. This all screems '1337 Haxor Dashboard!!!'. I have no idea whom I am supposed to impress with it. But I know I get a headache from it.

Even using the browsers defaults would go a long way. White background, black text, normal font, normal size. Plus a static feed in the middle of the screen. And nothing much else.


> Federation is cool. I have the feeling it needs its "Ubuntu Moment".

When federation is done 'right' you don't even notice it. Email for instance.

In my opinion social networks being in silos is as silly as something like email being in a silo. Really what we need is user buy in and that probably means figuring out how to interoperate with the various social networks like facebook and twitter.

It would be cool if the big social networks started thinking about breaking out of their silos and instead trying to be the gmail of federated social networks.


In the IndieWeb community we had that for a long time, we communicated with Facebook via their API so we could cross post posts, pictures and comments which would live on our websites but would also be posted to Facebook.

Since about a month ago Facebook removed that possibility https://github.com/snarfed/bridgy/issues/817

Because of that, I'm not sure it's worth to try to integrate with projects which don't have an incentive to be part of something bigger.


The big ones have no reason to break out of their silos. FB is worth $500B. They want to build walls around that. Walls as high as possible.

It's a chance for small players. If there is a future where federated social takes over the silos, then betting on it now would be a once in a lifetime opportunity.


You're not wrong, but if history is any indicator: tech companies need to innovate or die. I'm not convinced facebook is here to stay.


What's a "silo". My emails exist on gmail's servers. Is that not a silo?


They exist on gmail's servers, but you can send and receive emails from protonmail, yahoo, or self-hosted email addresses.


And receive email relayed via smtp servers - others don't have to connect directly to gmail/Google to send you mail. (modulus aggressive spam filters).


Several of these things are being actively worked on. For example, PixelFed is an Instagram clone built on top of ActivityPub that currently looks like this https://mastodon.social/@pixelfed/100229934638171208 (screenshot, not a link to a live instance) and Aardwolf is an in-development federated social network that's intended to have a Facebook-style interface https://github.com/Aardwolf-Social/aardwolf

They're not there yet, but people recognize their necessity and they are in the works!


Super interesting. I am eager to try those out.


> I wonder what would happen if ActivityPub was used to build Twitter/Instagram/FB alternatives with less aggressive advertising. But with the same user friendly interfaces.

What path would lead to less advertising? Email is federated, but is still dominated by a few vendors who rely on advertising.


That is a very interesting question. My assumptions are:

1: Running a ActivityPub server is much much cheaper then building a hyper growth company like Facebook. So less revenue is needed. I would expect that an AP server running on a cheap VM for less then $100/month can handle many millions of monthly users. I know admins of other systems, serving a million monthly users with a $10/month VM.

2: Facebooks valuation per user is insanely high. The company is valued at over $200 per monthly user. The average site owner would be happy with just 1% of that. I know people who built communities with a million monthly users. And they are not worth millions. Let alone hundreds of millions.

3: I think there is a better way of advertising then the aggressive approach we see on FB, Twitter etc. It might not work for super big companies. But I have the feeling that a site owner who caters to say 10 million users could get a few sponsorships and make 5 figures monthly with very very lean ads.


You might like Pleroma then: https://pleroma.social

Instance example: https://pleroma.site

One of the nice things about Pleroma is that you can "plug in" different interfaces to it. Each instance already comes with the option of both the Pleroma frontend and the Mastodon one. One of the devs is also working on a Facebook-like frontend.


Just tried it. Looks much better then mastodon.social Experience is a bit strange. When I toot something, it does not appear in the timeline nor does my statuses count go up. Both only happen when I reload the page.


You'll see a button appears on the top right corner of the timeline when you have new messages, with the number of new messages. You can press that to load them. Alternatively, you can go to the settings on the top right corner and change it so that it automatically loads new messages when you're scrolled to the top.

The instance has a "get started" link on the left that explains some stuff. And you can ask the instance admin kaniini for questions (who is also a Pleroma dev).


> Federation is cool.

I don't want to undermine the hard work of other people, but for the sake of completeness, know that federation has its critics on the decentralization scene.

I discovered that around the ssb community a couple weeks ago, the argument being that in federation model, people always end up choosing the same node, be it because it has more users (like diasp.org for diaspora) or nicer interface (like gmail for smtp), and it just ends up in centralization again. Here is an article discussing it : https://secushare.org/federation

The alternative is to forget about the client/server model entirely, and have distributed database hosted by clients and synchronized through p2p. Secure Scuttlebutt (ssb) is an attempt at that, through the gossip protocol ( https://en.wikipedia.org/wiki/Gossip_protocol ). The idea being that clients can synchronize with each other directly, even without the internet, using only local network, and transport encrypted data meant for other people (so the data propagates).

From what I understand so far, ssb makes this possible by implementing a database inspired by blockchains : each user has its own append-only database on which you can add an encrypted entry only by signing them with a private key, that people can verify and decrypt using your public key (and their secret key, if it was a private message meant for them).

The networking part still use federated-like nodes (actually regular clients, but running on hosts without firewall) to workaround the fact that most people are behind firewalled NAT and can't listen to ports. The important part here is that one of those nodes (called "pub") can disappear, it won't affect you, even if you first accessed the network using it : your data is on your machine, the pub only help finding peers and can be replaced at any moment (you quickly discover other pubs after the first one), and even is not needed if your peers are on the same local network than you (perfect tool for a family private social network, btw).

Now, while I find ssb cool and that's the project I want to work on, I find secushare article I mentioned above unnecessarily harsh and definitive. A problem has been spotted on in the federation model, it doesn't mean it can't find any solution. For example, a protocol based on federation can forcibly limit the number of users per node (although, the service could just spawn several nodes), or an other incentive for distribution could be created. I'm pretty sure there are a lot of smart people working on this.


People should have learned the lesson from federated email VS Gmail: federation works only when people don't have a compelling reason to stick to one service provider.


there are a few alternate web user interfaces that work with the Mastodon client API (which Pleroma also implements); halcyon and pinafore being two of them. To be more specific, Halcyon's UI is Twitter-clone.


Urls? Tried to google these, but did not find anything.



Halcyon: That is supposed to be a Twitter clone?

First page already looks way more complex and flimsy then Twitter.

Then I click on 'or create an account' and I am redirected to mastodon.social. WTF?

Pinafore: I don't understand what I am supposed to do with it.


Brutaldon is even more pared down skin (and offers an even more Web 1.0 brutalism beyond that): https://brutaldon.online/

Most of the skins redirect to mastodon.social on the Create Account link because they don't host the accounts themselves, they just offer views for whatever account(s) you do have.


Sorry, but that is not brutalism. That is just a badly designed page. Small grey font is pretty much the opposite of brutalism. So are small pastel colored buttons with rounded corners.

It looks like a bootstrap theme but with all spacings done wrong.


Brutalism is in the eye of the beholder, of course, and any talk of Brutalism on the web is an exercise in analogy given that the core mantra of architectural Brutalism was to stay "true to the materials" and for pixels it's hard to be "false" with them.

The variation of the theme that just uses HTML2/3-esque TABLEs and table borders is definitely more directly evocative of that spirit, stripping away CSS for just the brutal truth of classic HTML design. I tried to find a direct link to that version of Brutaldon's theme, but am not sure where to find one, and searching one's Mastodon feeds from weeks seems to be tougher than I expected.


Halcyon and Pinafore are both just front-ends for existing mastodon accounts (like brutaldon).

Pleroma is a different technology, but federates the same. As is Misskey; depending on what you're looking for in features either of those might do it more for you (or the glitchsoc fork of mastodon). (and theming is a thing, of course, regardless)

It's been posted here before, but http://fediverse.party/ is a nice little overview of the federated social web (over ActivityPub, I believe); https://the-federation.info/ is broader. Both have some small issues but are nice starting places.


My exact reaction. I have tried using Mastodon, but that thing is designed by engineers with no common design sense. Just sticking to browser defaults would be a huge improvement. It looks like something I should use to impress 15 year olds with.


Here's the thing I don't really get about Mastodon (and by reverse extension ActivityPub):

Say I'm interested in Video Games, so I join a Mastodon instance all about video games. Also, I'm interested in FPV Drone Racing. Should I join a second Mastodon instance about FPV drone racing? If I do, then I have to switch back and forth to use them (and for every other interest I might have). Which isn't too difficult, but seems to defeat the purpose of federation. If I just follow FPV drone racers from my Video Gaming account, then I am polluting the federated timeline of the Gaming instance with stuff other people on it might not be interested in. Also I have to follow each account on the FPV Drone instance manually and don't get the local timeline of that instance.

It seems like federation would be more useful if accounts were federated as well - like once I have an account on one instance I can use that account to join other instances as well. Or if it were more like email where the server you're on doesn't really make you part of that 'community' - it's just a place to store your stuff. Maybe I'm using it wrong?


This is exactly how the XMPP network is made and how the social features that we are building around are designed :) You use the same XMPP account to login to different instances and everything is synchronized from the server your account is on.

You can try it on https://movim.eu/, we propose several instances across the world and you can login with the same account between them (it's still better to pick the one that are geographically closer to you to have a quicker load time).


I'm really happy to see more applications published using Rust (and Go). Without even looking, I know I'll be able to run Plume on commodity hardware.

PHP, Ruby, and Java programs seem so wasteful when it comes to memory. Especially PHP and Ruby where re-using any of the codebase for a mobile/desktop app is often close to impossible.

Consider the Plume install vs Mastodon (Ruby):

- https://github.com/Plume-org/Plume/blob/master/DEVELOPMENT.m...

- https://github.com/tootsuite/documentation/blob/master/Runni...


In my experience, PHP is super lean and fast.

You definitely can run PHP software on commodity hardware. The typical LAMP application based on Laravel or Symfony runs just fine on a $5/month VM. And will serve something like a million monthly users without breaking a sweat.


I used to write a lot of PHP. My framework, MicroMVC was faster and lighter than the original phalcon framework (written in C) according to the techempower benchmarks. In fact, in round 3(?) it was the fastest PHP framework period (and it included an ORM).

I still think PHP and Ruby need to be depreciated. I would never start a product using either in this day and age.


> I still think PHP and Ruby need to be depreciated. I would never start a product using either in this day and age.

Why? Only because they take more memory than Rust, Go, or C? Or is there another reason?


- stdlib full of edge case problems causing you to second-guess and double-check things. I had to write so many libraries to wrap core classes like libxml.

- No support for multiple CPU cores

- UTF-8 is still a second-class citizen

- Not strongly typed

- High memory usage

- Slow execution

PHP and Ruby can't even serve themselves safely over HTTP and they are web languages. They offer nothing that isn't better handled by Go and Rust. Even Node is a better choice thanks to non-blocking I/O, the huge talent pool, and the ability to reuse code on the frontend, desktop, and mobile.


Thanks for the clarification. I think those are fair points.

BTW, do you think Rust would be a good replacement to Ruby for companies trying create an MVP? Or do you think Go and Rust are more for the optimization/scaling phase?


Speaking for Ruby/PHP web apps. Go is not quite as fast as Rust, but much easier to pickup since it has a simple syntax and manages memory for you. I would save Rust (or C) for the optimization phase since finding developers is harder.

Go is so good that huge companies like sendgrid, cloudflare and google never move past it. Rust is great for hardware and embedded devices where memory management really, really counts.


On a similar way we already built a "Blog" solution on XMPP. This is relying on the Pubsub extension and some others (like https://xmpp.org/extensions/xep-0277.html).

Two projects are already implementing it for several years Movim (https://movim.eu/) and Salut à Toi (https://salut-a-toi.org/).

Here is the official blog of the Movim project https://nl.movim.eu/?node/pubsub.movim.eu/Movim. It already supports comments (and likes), edition, attached files and urls, tags, richs texts and many other things. The posts are published and distributed in real time across the XMPP network and you simply need a XMPP account (and a recent server) to enable it :)

The big advantage to rely on XMPP is that this also allows us to use the many other features provided by the protocol. If you subscribe to someone blog, you can also chat in real-time with him, do video-conference, across lots of different clients on lots of devices, invite him to chatroom… all those things are not possible with ActivityPub and will require "another protocol" to do that.

On the contrary, the "blog" feature is more seen as a little piece of XMPP (that is also an IETF standard and implemented in several servers already used by hundreds of services accross the world (see https://xmpp.org/uses/ )).

One final thing, because XMPP is built on XML, the "blog" feature is simply Atom elements published in Pubsub. No new standard, just some good old XML things put together. Creating a simple HTTP-Atom feed from Pubsub is then easy-peasy (https://nl.movim.eu/?feed/pubsub.movim.eu/Movim and the other way around https://github.com/edhelas/atomtopubsub/) :)


Disappointed it requires postgres. We need to be focusing on running some of these things at home with small, mostly self-contained desktop-style apps. Many people have always on home machines (or this stuff could justify one). NAT busting has been mostly solved, but you could use something like Tor onion services otherwise.


I've opened an issue here, feel free to +1:

https://github.com/Plume-org/Plume/issues/93


I had the exact same reaction. As much as I love postgres for monolithic business systems, its a horrible choice for something that to see meaningful adoption needs near-zero barrier of entry. if it can’t easily download and run on an rpi it seems like a poor architecture for the use case.


Why can't you run postgres on a rpi?

Isn't installing postgres as easy as mysql aka 'apt install mysql-server'?


I thought I was going to be the only one to raise this issue. Not only are the advanced features of postgres unnecessary, these types of fleeting platforms don’t really need to have their histories maintained. HN runs without a DB just using flat files, IIRC.


This makes it super easy to create a blog! So easy, I even managed to create the following blog without even registering. (Yes, it seems that empty-username:empty-password is a valid login on this service.)

https://baptiste.gelez.xyz/~/MyLiveDemo

Also it seems that the "new article" functionality is broken, which is pretty important for a blogging service without any content.


So this acts as an ActivityPub inbox (comments) and outbox (publications)? Brilliant! I had been toying around with the same idea the past few weeks.

Go ahead and try searching for @BaptisteGelez@baptiste.gelez.xyz in Mastodon, then toot-reply to one of the article toots (from Mastodon) - your toot will show up on the blog post as a comment after a few seconds and a refresh.

Great work!


Is there an ActivityPub aggregation service that lets me run Plume, Mastadon, PeerTube, etc all on the same domain? Or will people always have to follow me three times...


This can be done by, say, boosting the Plume/PeerTube content from Mastodon.


Choice of name seems a bit unfortunate.

My immediate thought when looking at title was something to do with the Android Twitter client Plume.


Not to be confused with Plume Creator, an open source tool for writing novels and short stories:

https://plume-creator.eu/


This is awesome.


Indeed, can’t wait to get rid of the those “We’ve seen you here before” nag screens Medium imposes.


Safari -> "Use Reader automatically on 'medium.com'"


Wow, thanks for the tip!


"Let's make it official"

very annoying


Not arguing, but Medium is more than the votes & articles. It's the totality of the experience (from reading/metrics to emails & recommendations to paywalls & payments). I'd hardly call this medium - its a distributed blogging platform.


I guess they might be thinking of the syndication. Medium allows anyone to post, and suggests articles from different authors. This is similar. It enables blogs (if they use activity pub) to be syndicated throughout the blogosphere.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: