Hacker News Reader

Comment by mariusor | Hacker News Reader

> What we really need in this landscape is dead simple services.

I'm working on exactly that: a service that acts as an ActivityPub server (code[1], example[2], example application running on top of it[3]) for users in the form of a static binary. It supports multiple storage backends that can be selected individually or all together at build time and it can be extended to many more.

[1] https://github.com/go-ap/fedbox

[2] https://federated.id

[3] https://littr.me

View on HN

This is exactly what we need. The current landscape of Fediverse is too young: every application involves both functionality, identity and community. So you don't really join a network, but you join a specific community using a specific medium. You can't join multiple communities (ie follow multiple instances): you have to create multiple accounts, you can't follow a full instance but only individual instances. You can't have microblogging and forums from the same account, because they are different applications, so they are different accounts. You can't mix functionalities beyond the most basic, because they are not thought out together.

What we need is an AP store, and then applications build on top of it, like your project does. But at this point I question whether matrix wouldn't be a better platform

Some clients allow you to pin the public timeline of another instance. As for spreading beyond your home server, tags are key. With the right client, or the Mastodon web UI in advanced mode you can pin a series of tags as its own timeline, which updates in real time, so you can follow discussions of interests, grouped together, with results from across the Fediverse.

That sounds very nice and I must admit I haven't made a lot of research on this topic. But today the major servers are still sold as a building block for an "inside" community. You browse instance that are categorized by interests.

Basically, the domain has much more significance than it really needs

I feel like matrix solves a different problem, I believe that ActivityPub and Matrix can coexist. Honestly the very late game plan for the projects I'm working on is to be able gather under a single umbrella a suite of opensource applications to create a meta social network pod that can be easily launched in a similar way to Google apps on a custom domain (ActivityPub and Matrix for a starters). I think there could be enough money in that to gather venture interest, but sadly I'm very far from that moment.

I'm working on flockingbird.social, a "linkedin for the fediverse"[1].

Aside from a job-search bot, I haven't written many software, and it looks like what you are working on might actually be a very solid foundation. It's a pity my go isn't that established (rust and ruby here) but certainly will consider this going forward. Huddling around common base libraries is also certainly something the fediverse needs, rather than re-building AP again in "language X".

[1] The hardest part has proven to be the fact that "linkedin" is an entirely different product depending on who you ask. It solves entirely different solutions, depending on who you ask. And it has entirely different features, depending on who you ask. Turns out LinkedIn is quite hard to "copy", "port" or even define for the fediverse. Aside from that this makes it a giant task to do. Is it a place to find jobs? To recruit? To keep in touch with colleagues? To connect with other entrepeneurs? To spam lame motivational quotes? To pitch your book or a Rolodex-on-steroids? Its all of that and more.

If you're working in rust I would recommend to have a look at the go-ap/processing[1] package, which provides a close representation of what the ActivityPub spec details about how to handle each Activity type. It's not complete at the moment, but it should be readable (I think) even for non Go developers and, in my experience it's not the vocabulary that trips people up.

For your use case you probably need to define your own custom ActivityPub types and logic, but for the default ones, it's a good starting point (I hope). :)

The go-ap org on github has a mailing list you can reach if you have questions or feedback.

[1] https://pkg.go.dev/github.com/go-ap/processing#CreateActivit...

Contrary to the way matrix is developed and sold today, the protocol allows for way way more than chat.

There is talk at the moment about adding federation to got forges: let instances talk together, accounts cross post, etc. It's centered around instances and they have specific addons to interact. Matrix can make it work because it takes a radically orthogonal approach: rooms are front and center. Rooms can be joined by anyone anywhere. Rooms are replicated. The homeserver is a technical detail in service of the functional source of truth: the Room, an append-only log of arbitrary json. There is also a key-value store for arbitrary blobs to store binary stuff.

In the context of forges, a repo can be a room: events for issues/replies, events for merge requests, events for CI/CD blobs for actual code storage and releases, ... Anyone can join and push events, with the correct rights of course, so you have branches included. Everything is replicated. No one cares what instance you are from.

I seriously invite you to consider the semantically model of Matrix, it's pretty good.

Do you have plans to add comment functionality to littr.me/go-littr?

I don't understand the question, it already supports comments. littr.me is basically a link aggregator and discussion platform that's very similar in UX to (old) reddit, hacker news and lobste.rs.

I wasn't expecting permalink to be the comment section. Very cool project! I'm always on the lookout for an altruistic reddit contender.

Granted, it wasn't the best name.

I changed it to "discussion" based on your feedback: https://todo.sr.ht/~mariusor/go-activitypub/261

Reply on news.ycombinator.com