Problem: I don't know what I'm doing and can't figure out how to
cross-compile this simple C program to macOS and Windows
Solution: @cryptix reminded me that Go makes cross-compiling easy, so I
took a stab at writing my first Go program. It seems to be working on
macOS and Linux, but I haven't tested on Windows.
Problem: Apparently one of the previous commits switched us to
shell-style argument expansion.
Solution: Use the appropriate solution on Windows, `%*`.
Problem: We were using `darwin` instead of `win`.
Solution: Replace `darwin` with `win` to ensure that we're using the
correct path in the batch file we produce.
Problem: When running the Darwin binary from another directory, the
script would look in the user's current working directory for both
`node` and `src`, which is wrong.
Solution: Set `BASEDIR` and use it so that we use the correct paths.
Problem: I've quickly learned that cross-compiling is a major headache
and that C programming lacks both rainbows and butterflies. It seems
that my executable only works on Linux, but probably not macOS or
Windows.
Solution: Use shell scripts on macOS, which work when you double-click
them, and batch scripts on Windows, which I *think* work when you
double-click them. I haven't tested this on a macOS device yet, but I
tested the previous shell script on macOS and it seemed to work fine.
Unless I've done something silly, this should work on macOS, but the
Windows batch script is just me writing code from memory and probably
doesn't work correcly. I'll probably beg @SoapDog to help me fix it.
Problem: Writing C in a heredoc is super janky and I think it's worth
avoiding whenever we can. We've also been getting compiler warnings that
we should probably resolve.
Solution: Move the C to its own file and resolve the compiler warnings.
Problem: The shell script didn't work on other platforms and the
AppImage hack ended up confusing people who tried to install it with
AppImageLauncher.
Solution: This feels absolutely ridiculous, but I've written the worst C
program in the world which does the equivalent of `exec ./node src "$@"`
and immediately gets out of our way. This ends up being an executable
that both Nautilus and Dolphin (GNOME and KDE file managers) let us
double-click, and should also work on macOS. It might even work on
Windows if we rename it as an `.exe`, but I'm not sure and *definitely*
haven't tested that.
Problem: We try to `require()` our native modules to ensure that they
work correctly, but when they don't work we need to produce an error
that will help us debug the problem.
Solution: Switch from `node -p` to `node -e` to avoid printing
unnecessary output and don't redirect output for mandatory modules so
that we can debug them.
Problem: The installer contained npm and npx and a bunch of code that we
really don't need unless we're building from source. Since we don't want
our end-users to build anything from source, we can remove these.
Solution: Use shell-check to make some small fixups to the code and
remove everything we're downloading via wget except the `node` binary.
This requires moving the "build from source" fallback, and also includes
the `.appimage` hack when building from Linux to get double-click
opening working.
Problem: The previous approach of having the installer run `npm install`
was hazardous at best and didn't work well offline.
Solution: Package all of the source code with the application and use
the installer to ensure that it works on the target device. The
installer should ensure that we can `require()` the module, and if that
doesn't work then it should choose between two options:
- If the module is optional, `rm -rf` it and don't worry about it.
- If the module is mandatory, try running `npm install` with some flags
to ensure that we stay offline and print the absolute minimal output.
This should never happen, because we should never be packaging Oasis
for architectures and platforms that we don't have prebuilds for, but
it's a fine fallback behavior for experimental hackery.
Problem: Running `./oasis --version` should output the current version,
it shouldn't just start the server by default.
Solution: Pass through command-line arguments with `$@` so that we
respect what the user is asking us to do.
Problem: Most people don't have npm installed and we probably shouldn't
force them to have a full development environment to use Oasis. It would
be nice to have a way to install Oasis without any development tools.
Solution: Add a build script that can create .zip files that work on
Unix systems like macOs and Linux. Users will need to download the zip,
extract it, and double-click the `oasis` script. This script will run
`npm start || npm install && npm start`, which uses binaries that we
ship in the zip file so that they don't need to have `node` or `npm`
installed.
Problem: I thought `--no-optional` would just ignore our top-level
optional dependencies, but it ends up ignoring deep optionl dependencies
like sodium-native. We really want these dependencies if we can build
them.
Solution: Remove the `--no-optional` suggestion and add a note about
what to do if Sharp doesn't install correctly, which is very likely
since Termux doesn't have libvips available.
Problem: The Termux install is new and exciting and there isn't any
documentation on how to experiment with it.
Solution: Add some documentation like we've done with systemd and
Docker so that we can collaborate and figure it out in the repo!
Problem: We've been using a workaround to filter the results of
SSB-Mentions, but that's just been fixed upstream and so we don't need
the workaround anymore.
Solution: Update the SSB-Mentions package and remove the workaround.
Problem: During the SSB-Query refactor I used `{ private: false }` in an
attempt to hide private messages, but apparently this option is only
available via SSB-Backlinks, so it was ignored without any warning (!).
This allowed private messages to be displayed in public views.
Solution: Remove the unused option and add a filter to public views that
ensures that private messages are always hidden.
Problem: Private messages should only be showing up in the Private page,
not the Mentions page, but right now they're showing up in Mentions.
Solution: Add a check to ensure that Mentions doesn't have any private
messages.
Problem: When the port was already taken by another process we've been
dumping a big esoteric error message that really isn't helpful for most
people.
Solution: Catch the error and give our users a friendly error message
with a suggestion on how to run Oasis on another port.
Problem: I added an image border to try to make it easier to see the
boundaries of images but it's not really necessary and at least one
person didn't love it, which is grounds for removal.
Solution: Get it out of here! This commit removes the image border and
also removes a random `console.log()` that shouldn't have been left in
`src/index.js`.
Problem: After publishing a message you were redirected to the Popular
view, which wasn't good feedback that your message had been published.
Solution: After publishing a new message, redirect to the Latest view.
Problem: It was impossible to tell which version of Oasis you're
running, which makes it hard to know when you need to update.
Solution: Put the version in the settings so it's easy to reference.
Problem: The `messagesByType()` queries don't let us sort by asserted
time, which means that we can get messages from a long time ago that
just ended up on our computer.
Solution: Use SSB-Query everywhere. The query syntax isn't really my
favorite but it lets us make declarative queries that respect the
asserted timestamp instead of just the received timestamp.
Problem: The npm registry is great for proprietary modules who need to
ship binaries but not really useful for free and open source software.
It creates a divide between users and our Git repo, and introduces a
for-profit company as an intermediary to distribute Oasis.
Solution: Remove the npm registry as a distribution platform and just
use our Git repository instead. This removes npm registry references
from the readme, instead prioritizing the GitHub repository, and leaves
room for others to mirror the Git repository (for allows us to move to
less-Microsofty Git hosting).
Problem: It's hard to know who has worked on the project and who is
maintaining the project, for security and code of conduct issues.
Solution: Add AUTHORS and MAINTAINERS files to track who has contributed
code and mixed in their copyright (woo!) and keep track of who is
committed to maintaining the project and merging patches.
Problem: There wasn't an easy way to copy and paste a message ID, feed
ID, or blob ID and get directed to that page in Oasis.
Solution: When someone pastes one of the above into the search, just
redirect the browser to the correct page rather than searching for that
text.
Problem: Until we have a way to change the view of each page, it seems
to me that each of the views that we're experimenting with should be on
their own page rather than modifying the existing pages to add more
functionality. I'm also noticing that I can't process all of the
information that's on the screen when the new horizontal layout is used,
and I think we would benefit from using the previous layout
consistently.
Solution: Move the summary view to its own page so that we can continue
to iterate on it without modifying the popular view, which is already
complex, and revert the style changes to maintain consistency with the
rest of the linear design (threads go downward, indentation denotes
sub-threads, etc).
Problem: Recently we refactored the code so that we calls over MuxRPC
used promises, which was incompatible with the client-side SSB-Tangle
plugin that was expecting a callback. While debugging this error, I also
noticed that our `{ ws: { http: false } }` code wasn't doing anything,
and that our connection error handler was handling all kinds of
unrelated errors that would make debug more difficult.
Solution: Use `util.promisify()` to convert the callback-style function
into a promise-style function, remove the unused SSB-WS code, and reduce
the scope of the error catcher so that it'll continue to output errors
unless they're "cannot connect to sbot".