I wrote a blog post about various myths: ta180m.exozy.me/posts/forge-fe

As usual, feel free to ask me questions about forge or federation!

According to my nginx log, 85.49% of the viewers of that post were bots 😦

@ta180m if you're reading your access logs, I'm the maniac who read that post in eww

@ta180m almost every instance fetches to generate an embed!

@ta180m The main reason I like gh is for project discovery. People can find my stuff and I spend (too much) time looking on gh for cool projects I should stay aware of.

Will gitea federation help replicate that or not really?
Will there be an option to follow (follow is the wrong word - flow through, index) all of an instance’s content so that self hosted instances don’t feel too seperated?

@daniel Gitea isn't working on discoverability, but Forgeflux's North Star project (github.com/forgeflux-org/north) is actively developing repo indexing and search for the entire ForgeFed federation.

For following an entire instance, we haven't really considered that feature, but you will be able to mirror individual repos including issues, PRs, and releases.

@ta180m Thanks for the brilliant response! Northstar sounds good, if it works, but seems a little bare bones atm. Hopefully it see more dev soon (that sounds kinda snobby - sorry). Is there any change for integration with such services (like with the explore section of gitea), or is it likely to stay as a separate tool

Mirroring including issues and PRs will be good, but I guess my second question doesn’t make the most sense without the first being in place.

@daniel I'm not sure if North Star will be integrated with Gitea. Currently, we plan on using the Gitea explore feature to search for all users and repos that this instance has interacted with (similar to Mastodon), but in the future we could definitely consider integrating North Star for federation-wide search or set up a separate service like Peertube's Sepia Search.

@ta180m Thank you for taking the time to answer my questions - great work for working on all of this!

@ta180m hello! i do have a few questions!
will you be using mostly Forge-specific activity types or will you use ActivityStreams core vocabulary? (i'm asking to know if it would be possible to interact from microblogging-related instance software (Mastodon, Pleroma, etc), for example to create or comment on issues, things like that)

@helene we'll be using mixture of ForgeFed types and core AS types. We plan on having features like commenting on an issue with a Mastodon account, but currently Mastodon violates the AP spec by ignoring any ForgeFed types: github.com/mastodon/mastodon/i

@ta180m How does this violate AP spec if the type is not supported by the remote server? (I don't remember seeing anything about this in spec, but I'd like to see, so things can be fixed)

Support for those types could be added in Pleroma, though, depending on what the issue is.

ActivityStreams supports using an array on `type` to specify that an activity may be multiple types (using e.g. the supported base activity type first, and the extended type second), which would help servers in understanding activities for types they do not understand.

@helene iirc the AP spec required servers to continue processing types that they don't recognize as best as they can. Mastodon could extract the name and content of ForgeFed ticket objects and render them as posts, for instance.

Type arrays are another solution, but Mastodon doesn't support them and go-ap, the library Gitea is using for federation, also doesn't support them the last time I checked.

@ta180m I've been looking at the spec, I don't see much about this. This would be acceptable behaviour for unsupported object types, but this could easily go wrong. I am not a fan of the idea, at all. For example, PeerTube creates a "View" activity for each time someone watches a video. If someone decided to refer to those in an `object`/`inReplyTo`/etc field on their activities, this would be a nightmare.

Type arrays can and should be supported, in my opinion. JSON-LD also has what's necessary for extending types, as well. Issues then come as to how to represent such types (should Repositories really be represented as accounts? how would one star an account from current Mastodon/etc? should Issues be represented as posts? should people be able to hellthread a repo's issues from a social network? emoji reacts?)

@helene @ta180m

Yea, I don't think "violate spec" is accurate. #ActivityStreams-core:

> Consuming implementations that encounter unfamiliar extensions MUST NOT stop processing or signal an error and MUST continue processing the items as if those properties were not present. Note that support for extensions can vary across implementations and no normative processing model for extensions is defined.

@helene I think you're working with the assumption that all clients must work with all activity types. That in my opinion is wrong. Doing a "best effort" thing on what a client doesn't understand seems enough to me. Best effort being handling the properties that the client already understands (attributedTo, inReplyto, name, summary, To, CC, samd)


@mariusor @ta180m the subject at hand is servers more than clients, and i don't believe it's unreasonable to not process activity types one does not understand, especially considering the examples i've given (and i can give yet more)

@helene @mariusor yes, that's right that this is about servers, not clients since Gitea isn't planning on implementing C2S, at least for now.

@helene for all the examples you gave above, I think they're all reasonable examples of servers processing types they don't understand. For instance treating repos as accounts is perfectly fine because you can follow repos, and treating issues as posts also makes sense so fediverse users can comment on them or even do emoji reacts.

@ta180m I think you're working under a misapprehension here, if your server is doing more with activities than just receiving them, handling their side-effects, and distributing them to recipients you are also a client, not just a server.

If you display an activity or its object in a format that is meant for human consumption, again, you are a client.


@helene it's possible that we have a different definition of what "processing" an activity means. In my opinion "best effort" processing of an unknown activity type means mostly distributing it to its local recipients, even if you work under the assumption that their clients don't understand the type.

If your server doesn't do that, then I think it can be called broken from a "federation" point of view because it interrupts the context/flow of an activity chain.


@ta180m @helene any advice on how to get into #activityPub related web development?

@len @ta180m @helene

You can start with this guide: socialhub.activitypub.rocks/t/

And find a lot of info on the forum. Don't hesitate to ask questions there.

Also I co-maintain 3 fediverse lists at delightful.club where you find a lotta codebases to learn from.

And use hashtags and @activitypub group when asking questions on the fedi.

Methinks you should read the spec again. Implementations are free to ignore extensions they don't know about.  The spec actually recommends  that if you wish to provide an extension  type such as a "Frumble" that can gracefully devolve into and be displayed as a "Note" you identify it as a [ "Note", "Frumble" ]. Some projects will try and display this. If you do this backward and call it a [ "Frumble", "Note" ] or just call it a "Frumble", and we have no idea what a Frumble represents, we've every right to throw it into the bitbucket.

@mike @helene Thanks for the correction. I'm actually not working on Gitea-Mastodon interoperability right now, and it was someone else that told me Mastodon was the problem and supposedly violating the spec. Also, Mastodon and go-ap (the AP library Gitea is using) both don't support type arrays, so that complicates any solution involving type arrays.

@ta180m The part criticising people for saying git is already decentralised I think is kinda lousy and dishonest. Calling it just a myth is a dick move.

@w the only reason I included it was because I get asked that question *a lot*. I'm not trying to be "dishonest" here.

@ta180m That doesn't change the fact that you included "Git is already decentralised" as the first section in an article called "Forge Federation Myths." If you wanted to say that GitHub isn't decentralised, then by all means go ahead. The kinds of people who say "git is already decentralised" are the exact kinds of people who are well aware of that. Whether it's intentional or not you're misrepresenting people, and also ignoring the biggest point those people tend to make (E-mail) in the process.

@w I'm sorry if my post offended you and I didn't mean to criticize or ridicule people that claim Git is already decentralized.

What I wanted to explain is that Git itself is just a fancy distributed filesystem, and needs something else like mailing lists or ForgeFed to be fully decentralized.

@w thanks for the feedback and I'll try to use it to improve the wording and explanation in my article.

@w @ta180m I hate Email. How many people have a domain name?

Gossip, CRDT are only mature recently. In the future, maybe a "repo" is a IPFS pubsub topic, and people subscribe to it for updates. Scuttlebus+Git already does this.
@sysinshell @ta180m This has nothing to do with the point I was making.
@sysinshell @ta180m I am not talking about how one thing is or isn't decentralised. I am criticising them for dismissing valid points as a myth. I don't give a shit about having this kind of argument.
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!