determine server to connect to by parsing username at account creation

[velartrill]

the primary purpose of this PR is to address #36 from a UI perspective and make account creation behave as expected. it does this by attempting to decode the "username" passed at account creation as a fediverse handle (either in the Mastodon @user@instance format or the pleroma user@instance format), and setting the base_url and username fields appropriately. if there is no @ sign after the username portion of the handle, we assume the user is connecting to the flagship mastodon instance https://mastodon.social, which is kind of awful but unfortunately the bitlbee plugin API does not appear to give us a way to abort the account creation and signal an error to the user.

this PR also resolves a number of compiler warnings:

• instead of hardcoding a reference to sed, doc/Makefile.am uses the appropriate autotools variable to determine which sed to use. this is necessary because the sed scripts used in that makefile use GNU-only extensions, and sed on BSDs is generally not GNU sed. partially resolves #38.
• certain code paths led to the parsed variable in src/mastodon-lib.c being passed uninitialized to bitlbee's json_value_free, which could wreak all sorts of havoc and will almost certainly prevent segfaults or worse going forward.
• unnecessary parentheses that were causing a compiler warning were removed.

[kensanata]

Feel free to submit another PR to add yourself as author and copyholder where you feel it is appropriate. :)

[kensanata]

I'm also interested in hearing what you think of c1f5d47 and 442f386.

[kensanata]

"i promise i can explain." Hahaha!

[kensanata]

I guess you wrote it partially resolves #38 and GitHub decided that this meant it actually resolved 38 so if you think there's something missing you'll have to reopen that issue again?

[velartrill]

bitlbee-mastodon now fully compiles on freebsd at least provided gsed and gmake are installed and gmake is used instead of make to build the library. i'd be comfortable closing this if we add a note to README.md about this dependency, though it might be better to see if we can remove the extension use trivially. i'll take a poke at that and see what it involves.

[velartrill]

oh, and regarding ownership: i'm fine with just assigning the copyright over to you; it doesn't seem worth complicating the project's IP situation over a relatively trivial bit of code :)

[kensanata]

I just compiled. I have two accounts. The first one is on octodon.social and since the default URL got changed, I can no longer log in as the default was changed to mastodon.social. I'm not sure too many people use the plugin but this is a surprising change.

[velartrill]

that's alarming. the only function i really touched was mastodon_init - is this called from any places besides the account add routine?

i just checked my bitlbee server and it seems to have no problem handling two accounts at a time with different servers - if you'd like to poke at it and see if the behavior is different from your server, let me know. i'd hate if this was OS-dependent somehow

[kensanata]

I guess it was used here.

[kensanata]

9a4f750 changes the default back to octodon.social

a54e0cf uses g_strdup to get the username into settings. Can you verify that it works for you? I tested it for two variants and it seems to work for me.

[kensanata]

As for the README: there are already mentions of NetBSD, FreeBSD and *BSD. Can you look it over and just submit the changes you want to make for the build tools?

[velartrill]

ohhhh i think i may know what the problem here is. when i was looking at the source for set_setstr() i noticed that bitlbee doesn't actually store values when they are equivalent to the default - it just marks the setting as "default value." in other words, the problem should only occur for octodon.social users, and only ones who are upgrading to the new plugin. those who add accounts with the new method will not be affected.

yes, the readme mentions the BSDs, but iirc only to say where the binary packages are in the repos. i'll add some documentation of the build process.

there's no point in testing a54e0cf; it needs to be reverted, as it creates a memory leak and has no positive effects. g_strdup() allocates the string on the heap (which is additionally slower than the method i used). there is a reason i wrote it the way i did. additionally, as this behavior is caused by a bug in a library we rely on, the explanatory comment needs to remain - the behavior simply looks like a mistake otherwise and any reasonable coder would refactor the g_strdup() call into a simple pointer pass, which only introduces subtle bugs in one particular codepath, meaning the bug would likely go unnoticed for some time.

[velartrill]

🙃

i'll remove the code that produces this

[kensanata]

Yeah, that message should have been removed. :)