$ ipfs version
ipfs version 0.12.2

$ git clone --depth 1 https://github.com/mrusme/superhighway84
$ cd superhighway84
$ nano go.mod        #modify ipfs version from "github.com/ipfs/go-ipfs v0.11.0" to "github.com/ipfs/go-ipfs v0.12.2"
$ go mod tidy
$ go build .
$ killall ipfs
$ ./superhighway84
2022/04/16 00:55:38 loading configuration ...
2022/04/16 00:55:38 initializing logger ...
2022/04/16 00:55:38 initializing cache ...
2022/04/16 00:55:38 initializing TUI and loading database, please wait ...

# It seems it will wait forever

It has been reported that the number of connections IPFS creates makes it tricky to run Superhighway84 on especially older hardware.

It was mentioned that apparently this is a known issue in IPFS:

The libp2p team is currently refactoring the "dialer" system in a way that'll make it easy for us to configure a maximum number of outbound connections. Unfortunately, there's really nothing we can do about inbound connections except kill them as soon as we can. On the other hand, having too many connections usually comes from dialing.

I couldn't find out what the status of the libp2p refactoring is though. However, people are mentioning that disabling QUIC in the IPFS repository has helped a bit with the issue, e.g.:

... ipfs init --profile server, and (3) I removed the lines of quic under Addresses.Swarm in ~/.ipfs/config.

and

I fust followed the advice here of disabling QUIC ipfs config --json Swarm.Transports.Network.QUIC false

Another idea could be to try and press Superhighway84 into a set of iptables rules that limit its available bandwidth and the amount of connections artificially. I didn't investigate whether that really works, but apparently other users have done that for IPFS.

On my mac superhighway84 slams all the cores on startup for a few minutes, then ramps down to just using one entire core. This seems ...suboptimal.

If there's anything I can do to help debug let me know.

Hi,

I cannot get superhighway84 to go thru the first run. This is what gets output:

2022/05/30 19:42:53 initializing logger ...
2022/05/30 19:42:53 initializing cache ...
2022/05/30 19:42:53 initializing TUI and loading database, please wait ...
2022/05/30 19:42:53 initializing database ...
2022/05/30 19:42:54 connecting database ...
2022/05/30 19:52:54 unable to open database: unable to fetch database manifest: failed to get block for bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4: context deadline exceeded
panic: unable to open database: unable to fetch database manifest: failed to get block for bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4: context deadline exceeded

	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x1292fe7]

goroutine 1 [running]:
github.com/mrusme/superhighway84/database.(*Database).Disconnect(0xc00218d2c0)
	/home/runner/work/superhighway84/superhighway84/database/database.go:224 +0x27
panic({0x13e68e0, 0xc004195c40})
	/opt/hostedtoolcache/go/1.18.1/x64/src/runtime/panic.go:838 +0x207
log.Panicln({0xc0055ebf48?, 0xc002030e70?, 0x1832397?})
	/opt/hostedtoolcache/go/1.18.1/x64/src/log/log.go:399 +0x65
main.main()
	/home/runner/work/superhighway84/superhighway84/superhighway84.go:124 +0x8dd

The log file says:

2022-05-30T20:32:19.632+0200	DEBUG	database/database.go:148	getting config root path ...
2022-05-30T20:32:19.634+0200	DEBUG	database/database.go:154	setting up plugins ...
2022-05-30T20:32:19.634+0200	DEBUG	database/database.go:159	creating IPFS node ...
2022-05-30T20:32:20.287+0200	INFO	database/database.go:171	connecting to peers ...
2022-05-30T20:32:20.635+0200	DEBUG	database/database.go:124	connected!	{"peerID": "QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"}
2022-05-30T20:32:20.635+0200	DEBUG	database/database.go:124	connected!	{"peerID": "QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"}
2022-05-30T20:32:20.635+0200	DEBUG	database/database.go:124	connected!	{"peerID": "QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"}
2022-05-30T20:32:20.635+0200	DEBUG	database/database.go:124	connected!	{"peerID": "QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"}
2022-05-30T20:32:20.635+0200	DEBUG	database/database.go:124	connected!	{"peerID": "QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"}
2022-05-30T20:32:20.635+0200	DEBUG	database/database.go:177	connected to peer!
2022-05-30T20:32:20.635+0200	INFO	database/database.go:182	initializing database connection ...
2022-05-30T20:32:20.635+0200	DEBUG	database/database.go:51	initializing NewOrbitDB ...
2022-05-30T20:32:20.706+0200	DEBUG	database/database.go:79	initializing OrbitDB.Docs ...
2022-05-30T20:32:20.706+0200	DEBUG	baseorbitdb/orbitdb.go:531	open orbitdb store	{"address": "/orbitdb/bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4/superhighway84"}
2022-05-30T20:32:20.707+0200	DEBUG	baseorbitdb/orbitdb.go:553	Open database 	{"dbAddress": "/orbitdb/bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4/superhighway84"}
2022-05-30T20:32:20.707+0200	DEBUG	baseorbitdb/orbitdb.go:560	Look from 	{"directory": "/home/milan/.cache/superhighway84/database"}
2022-05-30T20:32:20.707+0200	DEBUG	baseorbitdb/orbitdb.go:575	address '/orbitdb/bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4/superhighway84' is valid
2022-05-30T20:32:20.707+0200	DEBUG	cacheleveldown/leveldown.go:88	opening cache db	{"path": "/home/milan/.cache/superhighway84/database/bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4/superhighway84"}
2022-05-30T20:52:20.636+0200	ERROR	database/database.go:186	%s	{"error": "unable to open database: unable to fetch database manifest: failed to get block for bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4: context deadline exceeded", "errorVerbose": "failed to get block for bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4: context deadline exceeded\nunable to fetch database manifest\nberty.tech/go-orbit-db/baseorbitdb.(*orbitDB).Open\n\t/home/milan/go/pkg/mod/berty.tech/[email protected]/baseorbitdb/orbitdb.go:597\nberty.tech/go-orbit-db.(*orbitDB).Docs\n\t/home/milan/go/pkg/mod/berty.tech/[email protected]/orbitdb.go:143\ngithub.com/mrusme/superhighway84/database.(*Database).init\n\t/home/milan/work/superhighway84-0.2.0/database/database.go:80\ngithub.com/mrusme/superhighway84/database.(*Database).Connect\n\t/home/milan/work/superhighway84-0.2.0/database/database.go:184\nmain.main\n\t/home/milan/work/superhighway84-0.2.0/superhighway84.go:108\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:255\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1581\nunable to open database\nberty.tech/go-orbit-db.(*orbitDB).Docs\n\t/home/milan/go/pkg/mod/berty.tech/[email protected]/orbitdb.go:145\ngithub.com/mrusme/superhighway84/database.(*Database).init\n\t/home/milan/work/superhighway84-0.2.0/database/database.go:80\ngithub.com/mrusme/superhighway84/database.(*Database).Connect\n\t/home/milan/work/superhighway84-0.2.0/database/database.go:184\nmain.main\n\t/home/milan/work/superhighway84-0.2.0/superhighway84.go:108\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:255\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1581"}
github.com/mrusme/superhighway84/database.(*Database).Connect
	/home/milan/work/superhighway84-0.2.0/database/database.go:186
main.main
	/home/milan/work/superhighway84-0.2.0/superhighway84.go:108
runtime.main
	/usr/local/go/src/runtime/proc.go:255

The database LOG file in .cache says:

=============== May 30, 2022 (CEST) ===============
19:42:54.143405 [email protected] F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·Se
qNum T·TimeElapsed
19:42:54.161259 [email protected] opening
19:42:54.161488 [email protected] F·[] S·0B[] Sc·[]
19:42:54.168994 [email protected] F·2 G·0
19:42:54.169012 [email protected] done T·7.728795ms

This is version 0.2.0 and IPFS is 0.12.2 running on Ubuntu 20.04.4. I ran ipfs init and accepted all the default values offered by superhighway84.

I've tried everything I could find without effect:

1. Setting ulimit to 2048
2. Setting net.core.rmem_max to 2500000
3. Setting ipfs lowpower
4. Also tried it on macOS
5. Tried the previous version with older IPFS, also unsuccessful
6. Tried compiled and prebuilt
7. Tried increasing the timeouts in database.go from 600 to 1200

What else can I try? I would appreciate some hints.

Thnx.

Summary

Setting an absolute path to the log file (the default) prevents the application from launching on Windows.

Steps to Reproduce

Environment: superhighway84 v0.0.4 on Windows build 22000.348

1. Execute superhighway84.exe
2. Accept the defaults for the Initial Setup prompts
3. Specify a From name and accept other profile defaults

Expected Result

The application launches.

Actual Result

The application crashes with the following message:

SUPERHIGHWAY84

Initial Setup
-------------

Database connection string [/orbitdb/bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4/superhighway84]:
Database cache path [C:\Users\username/.cache/superhighway84]:
Logfile path [C:\Users\username/.cache/superhighway84.log]:

Profile information
-------------------

From [@localhost]: username123
Organization []:
2021/12/28 00:45:28 couldn't open sink "C:\\Users\\username/.cache/superhighway84.log": no sink found for scheme "c"
panic: couldn't open sink "C:\\Users\\username/.cache/superhighway84.log": no sink found for scheme "c"


goroutine 1 [running]:
log.Panicln({0xc00171ff50, 0x28, 0x29c6847bb11})
        /opt/hostedtoolcache/go/1.17.5/x64/src/log/log.go:368 +0x65
main.main()
        /home/runner/work/superhighway84/superhighway84/superhighway84.go:42 +0x1a5

Workaround

Set a relative path for the log file.

Unfortunately, this is not a permanent fix as the log file will be recreated several times based on the working directory from which the application was launched.

Notes

This seems related to parsing Windows paths in the logging module.

I received excellent feedback on the navigation through replies on Superhighway84 (thanks for that!) and understood that these would be some great improvements (to be extended):

• Use Tab for switching between lists
• Use Ctrl-Left/-Right for switching between lists
• Use single keys over Ctrl+Key combinations for easier navigation
• Add ? key shortcut to display navigation help

Feel free to add to this list. I will start implementing a few things soon.

╰─ go build .              
../../go/pkg/mod/github.com/ipfs/[email protected]/plugin/loader/load_unix.go:8:2: package plugin is not in GOROOT (/usr/src/plugin)

Getting the following error when building.

go-ipfs v0.12 was released. This introduced repo version 12. I upgraded IPFS, upgraded my repo, but now superhighway84 doesn't like it anymore, which is understandable:

panic: Your programs version (11) is lower than your repos (12).
Please update ipfs to a version that supports the existing repo, or run
a migration in reverse.

See https://github.com/ipfs/fs-repo-migrations/blob/master/run.md for details.


goroutine 1 [running]:
log.Panicln({0xc001d59f48, 0xc0000ec400, 0xc000181500})
        /opt/hostedtoolcache/go/1.17.6/x64/src/log/log.go:368 +0x65
main.main()
        /home/runner/work/superhighway84/superhighway84/superhighway84.go:87 +0x5e6

What's the plan? I'm using a separate IPFS_PATH for superhighway84 with repo version 11 now, which works, but I guess we'll have to upgrade at some point...

Pressing '?' or 'z' displays a help modal.

Currently displays some placeholder text and shortcuts. However the C- shortcuts are invisible characters.

Also does a little refactoring of the shortcuts.

I see one post to alt.social, but soon afterwards the system crashes with

ERROR┐╔═blockstore══════[email protected]/blockstore.go:218═════blockstore.AllKeysChan got err: walk failed: open /Users/emv/.ipfs-sh84/blocks: too many open files

As mentioned here it would be great if there was a way to see which messages were read already.

The easiest solution would be to simply store that information somewhere on the local disk.

I was reading your recent blog post and saw you mentioned that open files were causing memory issues, just wanted to open this issue about considering using Trustless IPFS gateways for fetching content as a way to reduce memory consumption from clients.

By using cid.ipfs.gateway.tld/?format=car, you can fetch a CAR file that allows "light IPFS clients" to fetch content without needing to worry about gateways mistakenly or maliciously giving the wrong content (since the cid won't match the root CID in the CAR file if it's been modified).

As pointed out in #42, if the local ipfs version is newer than the node used by Superhighway84, then people are unable to initialize a repo for Superhighway84.

It would be helpful if there was a way to make the IPFS node used within Superhighway84 initialize its own repository in case there are problem with the exiting one. This way we wouldn't be depending on the external ipfs binary anymore and users could simply run Superhighway84 without caring too much for IPFS internals.

This creates a 'server mode' SH84 that does two things:

• Work as headless peer to serve IPFS content
• Serves an RSS feed of latest articles (i.e. roots) or comments (i.e. all articles)

I intend to deploy this on my own server and add the feed URL to my newsreader, so I can keep an eye on posts without firing up SH84.

It's not actually serving RSS right now, but you can try it with:

$ curl localhost:8080/rss/articles
$ curl localhost:8080/rss/comments

I got an interesting suggestion on reddit:

Biggest immediate question: Can it interoperate with Gnus and scorefiles?

(The things I most miss from Usenet were literally the tools that let you make it reflect your interests and needs and not what someone else thought you ought to prefer.)

I haven't used the mentioned method so far, but maybe it makes sense to incorporate it as part of #19 and the overall subscribing/unsubscribing features that are still due to be implemented.

When I finish my post, I get a confirmation dialog, but the only thing visible is 'yes' or 'no'. Maybe this should display the post text?

Since I can't see what I wrote any more, I basically always hit 'yes'.