Add mastodon

[lil5]

• Sending messages to mastodon
• Sending messages from mastodon

[lil5]

@poVoq I tested it with my mastodon account ( https://social.linux.pizza/@lil5/115576520052387889 see how it says MatterBridge ) and an irc channel on libera

[poVoq]

Looks good in general, but it isn't so clear how the interaction works with the non-mastodon side? How would for example the remote nick be displayed in Mastodon?

In general, since we moved the documention into the repo, it would be nice if you could also add something beyond the basics in the example config toml. Thanks.

[lil5]

@poVoq Adding the docs to this repo is a great addition, I'll do my best.

The old repo reference was something I missed to fix after applying a .patch from my changes on the old repo, I'll fix it soon

[lil5]

@poVoq I had to migrate all internal code references to github.com/matterbridge-org/matterbridge I've kept all the documentation links the same.

[lil5]

@poVoq Done please take another look.

[poVoq]

LGTM, but maybe you could still try to fix those CI lint issues? You can see those on your end, right?

Ah and thanks for updating all the links!

[lil5]

Thanks, I hadn't noticed, I'll fix my editor to use the correct lint plugin, is it okay if I add a /.vscode/ with those edits?

[lil5]

# rules to deal with reported isues
issues:
  # Show only new issues: if there are unstaged changes or untracked files,
  # only those changes are analyzed, else only changes in HEAD~ are analyzed.
  # It's a super-useful option for integration of golangci-lint into existing
  # large codebase. It's not practical to fix all existing issues at the moment
  # of integration: much better don't allow issues in new code.
  # Default is false.
  new: false

  # Show only new issues created after git revision `REV`
  new-from-rev: "HEAD~1"

1. Rules for thee but not for me.

If I remove new-from-rev: "HEAD~1" and new: false I get a whole list of errors from older files

2. Overly strict code requirements.

I have some nonsensical lint errors like:

• Function 'JoinChannel' is too long (67 > 60) (funlen)
• bridge/mastodon/mastodon.go:239:3: missing whitespace above this line (too many statements above defer) (wsl_v5)
• gateway/bridgemap/bmastodon.go:10:1: don't use init function (gochecknoinits)

If fixed the first but that quickly comes back after adding empty lines before each if statement.

3. golangci-lint vscode integration

After adding custom settings to integrate golangci-lint into vscode, it only seems to output some of the many errors in the editor.

---

I have changed the golangci-lint.yaml and fixed all old code that contained issues.

[poVoq]

@selfhoster1312 you have an suggestion how to fix those linter issues? Or would you suggest to merge it as is?

[lil5]

@poVoq
The only leftover error on the last failed action is:

Error: unknown linters: 'wsl_v5', run 'golangci-lint help linters' to see the list of supported linters
  Failed executing command with error: unknown linters: 'wsl_v5', run 'golangci-lint help linters' to see the list of supported linters

No actual linting errors. I've tested golangci-lint locally but that is running the latest version (v2.6.2)

So I've updated to require golangci-lint 2.6.2 and go1.25. Editing what a github action runs only occurs after merging to the main/master branch.

[lil5]

Here's my terminal output:

➜  matterbridge git:(mastodon2) golangci-lint-v2 run
0 issues.

[poVoq]

Checks pass now, all green.

Thanks a lot for the contribution. Please stick around and help where you can!

[selfhoster1312]

Hello, thanks for the contribution! It's great to see a new bridge! On the dimmer side, i'm sorry to be complaining, but i'm rather unhappy that this was merged so quick, for a few reasons:

• it bumps the required go version without explaining why, which is not great for packagers
• it does very different things in the same PR: it changes the module name, tweaks CI, and adds code at the same time, making it very hard to review with 90 changed files
• the commits are not split logically: i'm ok to have separate commits for docs and code (though it's not necessary), but for example "Add documentation" and "more docs" should be the same commit to make review easier and not add so many entries to the git log (i'm happy to provide help with git rebase in IRC/XMPP channel)

I'm tempted to revert those changes and start again from scratch with different PRs for:

• renaming the go module
• making changes to the CI/golangci-lint (if it's really needed to remove all those checks)
• updating golangci-lint
• adding the mastodon bridge

I'm happy to take PRs for this in any order (and i'm also happy if other people review them without me, just taking a little more time and care). What do you think? @lil5 @poVoq i won't revert without your approval, do you think my concerns are warranted? If so, what do you think about that course of action? I'm also relatively OK to leave it like that (although that's not my preferred option) and admit this is a small harmless fuckup and we'll do better next time with proper contribution/review guidelines :D

[selfhoster1312]

I'll sleep on this before taking a decision, and other opinions are still welcome. @lil5 in case i do perform the revert, would you like to take the time to refine smaller PRs to get acquainted with higher review standards? I'm also happy to perform that dull work by myself, but i'm happy to take that time for you instead :)

[lil5]

Do what you want.

[lil5]

making changes to the CI/golangci-lint (if it's really needed to remove all those checks)

new-from-rev: "HEAD~1" I suggest you remove this line first, a config that only checks new code shouldn't exist.

[lil5]

the commits are not split logically: i'm ok to have separate commits for docs and code (though it's not necessary), but for example "Add documentation" and "more docs" should be the same commit to make review easier and not add so many entries to the git log (i'm happy to provide help with git rebase in IRC/XMPP channel)

If you're going to police git history messages of a feature branch I'm out.

[lil5]

it bumps the required go version without explaining why, which is not great for packagers

That's a fair point I didn't really have a reason other than to keep it on track with what my pc has which is latest.

[selfhoster1312]

new-from-rev: "HEAD~1" I suggest you remove this line first, a config that only checks new code shouldn't exist.

That's what i did initially in #2. Unfortunately it proved to be a lot of work and i'm not familiar enough with golang to make sure i'm not actually adding problems. So instead i kept upstream new-from-rev in #3. At least it ensures we don't add by accident new major problems, eg. by not checking error return codes.

If you're going to police git history of a feature branch I'm out.

I don't think anyone is going to police anything (the word is strong), but i think it's fair to expect contributors to take a few minutes to turn their draft into a proper copy and squash related commits (if any). Keeping history clean is not about making the reviewer happy, it's about making life easier for future contributors who will inspect how/when some code some introduced or modified.

I'm hoping we can come to an understanding with other/future contributors. I opened a dedicated issue. We already have some guidelines which for example mention golangci-lint should pass before submitting the PR, which to be fair is a little harsh, i think it's okay to accept contributions from people who don't have that program locally.

Do what you want.

Well the question is what do you want? @poVoq made a good faith mistake merging this before it was ready, and with so many unrelated changes, now we have to address it. Do you take part in it and learn how to better structure your contributions? Or is that a burden for you and you'd rather not?

Thanks for taking the time to contribute this mastodon bridge, and to reply to my interrogations. Feel free to drop by on the IRC/XMPP channel to get to know each other better :)

[lil5]

That's what i did initially in #2. Unfortunately it proved to be a lot of work and i'm not familiar enough with golang to make sure i'm not actually adding problems.

And here I've gone the work. You can try for yourself and it will not give any errors.

[lil5]

contributors to take a few minutes to turn their draft into a proper copy and squash related commits (if any). Keeping history clean is not about making the reviewer happy, it's about making life easier for future contributors who will inspect how/when some code some introduced or modified.

Let's agree to disagree