Feature idea

[chan] bitmessage
Aug 3 03:03

in keys.dat trustedpeer allows connect to one node change so multiple trustedpeer entries can be placed in keys.dat, either on separate lines or in comma or bracket separated list of entries. This would allow to automatically create a VPN of nodes with just one or small minority of nodes connecting to internet, all others not just syncing through gateway, but with whole VPN cluster.

[chan] bitmessage
Aug 3 08:35

People have suggested things like this before, for example so that Bitmessage connects only to nodes with .onion addresses. It's an interesting idea, but at the moment Bitmessage will connect to any node that it finds. If this is a problem, you can try PeerBlock, which is very easy to configure. https://en.wikipedia.org/wiki/PeerBlock As for connecting only to specific IP addresses, this is something for the developers to look at.

[chan] bitmessage
Aug 5 11:02

It sounds intresting, but there are few technical issues as I see.

[chan] bitmessage
Aug 5 18:24

Local nodes (ones not connecting to internet) would just need to assign themselves a connection ID for each connection. Then when AF_SOCKET bind checks the IP and finds a match, it would check for a connection ID. If the connection ID is unique, then it would allow the loopback connection. This would be very bad to do on a public connection but I see no problem on a lan. If someone is on your lan snarfing this ID tag, you've got bigger problems than worrying about bitmessage.

[chan] bitmessage
Aug 9 02:55

The problem is there is no context awareness in current implementations to allow for context-specific behaviors like that.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Aug 9 07:21

The development code has a peer discovery feature, which allows nodes on private subnets to automatically find each other and connect. I did some tests a couple of days ago to make sure it works. There is still some fine tuning left but in general it works, I tested it on linux, windows and mac, on loopback, LAN and a virtual network interface. Peter Surda Bitmessage core developer

[chan] bitmessage
Aug 9 08:43

No, I'm talking about proper awareness of context so that different policies for different contexts can be enforced. Consider a internet gateway node that also provides an archive service for two separate subnets. It may have policies that internet addresses should not be relayed to the private subnets nor should the subnet addresses be relayed to each other. Object-wise, internet objects can be freely relayed to/from one subnet but the other subnet is only allowed to receive select broadcasts - any objects generated by this subnet are never relayed to the internet. Both subnets have their own custom objects which can be relayed to the other subnet although there are constraints on the quantity, size, maximum TTL, and PoW difficulty of the custom objects crossing the subnets.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Aug 9 08:55

Policies based on subnets aren't useful, because bitmessage's security isn't based on IP addresses. The planned policy approach for bitmessage is to use CAs and TLS authentication, which can be applied to both server and client. You can still have gateways this way, but you don't have to worry about network topology and security of the physical layer. Peter Surda Bitmessage core developer

[chan] bitmessage
Aug 9 09:46

No, I'm talking about proper awareness of context so that different policies that different policies that internet gateway node that internet gateway node that internet addresses be enforced. I'm talking about proper awareness of context so that different policies that different policies that different policies that different policies that internet gateway node that different policies that different policies that different policies that different policies that different policies that different policies that different policies that different policies that internet gateway node that different policies that different policies that different policies that different policies that internet addresses be enforced.

[chan] bitmessage
Aug 10 03:30

We're working on it.

[chan] bitmessage
Dec 4 18:51

In blacklist, ability to blacklist incoming messages based on size and image content. Any messages over a user specified size from 32 bytes upward could be blacklisted. Instead of a slider just have a number entry box with a default like 1024 bytes. (size not counting payload's protocol data). Automatically detect MIME encodings like base64 so user can block images. I really feel no need to send or receive images. Bitmessage is a really bad option for that anyway due to size limitations and lengthy PoW. I'd like to automagically block all large messages and images. No doubt others would like to do the same.

[chan] alex jones
Dec 4 20:14

already done. look at "spamfilter" fork by torifier. of course, it was rejected from pyBM. but wth (what the heck) they say no pull request was ever done LOL

[chan] bitmessage
Dec 4 20:52

Why don't you get together with torifier and continue developing that fork?

[chan] bitmessage
Dec 5 02:35

Blocking based on size could also lead to false positives (e.g. lengthy rants) and thread backlogs. Another idea would be black-/whitelisting based on regex.

[chan] bitmessage
Dec 5 23:53

How about regex and size? That's a winner.

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
mass extinction of BM users Dec 14 04:51 2
the green light Dec 14 00:43 21
Safe chat software? Dec 13 23:07 18
torIRC 2.33 Dec 13 11:02 2
anyone uses Nyx for tor ? Dec 12 15:22 1
torIRC TBB-9150 version via port 11009 as always Dec 12 15:16 2
please post your onion and uptime in UTC London time in this list Dec 12 10:22 1
update torIRC , TBB-9150 version via port 1801 instead of 11009 Dec 12 09:28 1
torIRC , TBB-9150 version via port 1801 instead of 11009 Dec 12 09:14 1
torIRC latest - TBB-9150 version via port 1801 instead of 11009 Dec 12 09:13 7
bm as hidden service with stem Dec 12 03:11 10
sent via API : torIRC9050.py Dec 11 12:59 1
run bm in cloud: https://mybinder.org Dec 11 09:12 6
BitText XHKhFPCDzj: ultimate bitmessage forum Dec 11 03:10 1
BitText LIST Dec 11 02:39 1
Jupyter BM notebook with py2.7 Dec 11 00:34 1
firewall vs. pyBM green mode Dec 10 09:33 8
BREXIT IS BULLSHIT Dec 10 02:34 3
run bm in cloud Dec 9 19:13 6
The Stallman Tax Dec 9 14:47 1
using eclipse for pyBM & github Dec 7 15:28 7
BM w/ GUI : Jupyter BM notebook Dec 7 15:19 10
BM in python3? Dec 6 17:52 8
Listen for incoming on Tor hidden service Dec 6 15:43 12
questionable attitude Dec 6 08:09 21
why are all the channels blank Dec 6 06:24 11
Feature idea Dec 5 23:53 5
include the mammoth into pyBM source code Dec 5 11:18 1
include the mammoth into pyBM source code Dec 5 11:15 2
running the 800+ chan super mammoth Dec 5 10:20 32
the myth of the "secret chans" on BM Dec 4 20:23 1
[chan] DevTalk Dec 4 20:13 6
Hacking Bitmessage Dec 4 19:11 3
The complete full mammoth "keys.dat" file - replace your KEYS.DAT in pyBitMessage with this 800+ chan text file -- run the super mammoth ! Dec 4 16:23 2
clean up pyBM github landing page Dec 3 20:28 14
audit - squash this lil bug Dec 3 20:04 1
Error Dec 3 18:47 1
34C3 Dec 3 18:44 3
48 Dirty Little Secrets Cryptographers Don't Want You to Know Dec 3 17:50 1
mailchuck = OK ; onionmail = problematic Dec 3 16:27 6
mammoth chan list .py Dec 3 06:53 3
SUPER MAMMOTH -- 806 unique BM chans in one keys.dat file Dec 3 01:39 1
questionable attitude web.archive.org/web/20171202215905/http://bitmessage.mybb.im/viewtopic.php?id=30%23p106 Dec 2 22:42 1
ACK : Persistence via Dead Letter drop clearnet access w/Op separation Dec 2 12:42 1
OMEGA release 39 is available for download Dec 2 05:15 1
I get no reply from mailchuck upon registration -- fixed ! all working again. Dec 2 02:13 4
beamstat.com is fucking fast to serve broadcasts Dec 2 01:47 1
27'000 users who use OnionMail - more than BM ? sure ... Dec 1 10:40 1
beamstat.com is fucking slow to serve broadcasts Dec 1 10:34 4
Patch 4 Dec 1 10:31 5
crowdfunding : whack Trump Dec 1 10:31 11
27'000 users who use OnionMail - more than BM ? Dec 1 07:16 10
dotsendack =True *** stealth mode Dec 1 07:16 5
Pubkey request Dec 1 07:15 6
NEW ! subscribe to this pml : BM-NB4TuMJmrHeo1p1FsfuMCrkZBUPGLjnq Dec 1 07:15 7
Bitmessage feature request for timing attack mitigation Dec 1 07:15 14
How to disable ack packets Nov 30 13:07 36
Easter egg Nov 30 12:13 2
I get no reply from mailchuck upon registration Nov 30 11:40 8
easy mailer , just add MX line in DNS Nov 30 10:59 2
Feature request Nov 30 08:44 3
Bitmessage to Shell Nov 30 05:01 4
Patch 3 Nov 30 04:36 1
Patch 2 Nov 30 04:32 1
Patch Nov 30 04:18 1
Long delay making connections Nov 29 09:44 25
onion mail Nov 29 00:56 1
Flatpak Linux Distribution for Bitmessage Nov 28 20:19 1
sue corporations like stman sues postal services Nov 28 13:11 1
backbone member Nov 28 13:10 9
pyBM light load even on old laptops Nov 28 07:37 2
BM now with ding dong Nov 27 03:05 3
encryptpad Nov 27 02:52 2
The Homosexual Perversion: A Jewish Criminal Simhke for the Postmodern Corporate Conformist Nov 25 03:04 1
where is latest mammoth BM chan list ? larger than beamstat.com ? Nov 24 12:21 3
wayback archive for beamstat Nov 24 01:35 2
Where is PyBitmessage git signing key fingerprint? Nov 23 23:10 16
pyBM eating too many cycles still ----- fixed ! much better ! Nov 23 22:06 1
I'm back. Nov 23 21:50 3
pyBM eating too many cycles still Nov 23 21:34 4
wikileaks vault 8 Nov 23 17:02 3
very few active chans Nov 23 01:10 17
audit BM via web GUI Nov 22 20:37 6
But I'm using Tor!! Nov 22 12:38 2
LUKS! Nov 22 12:12 1
New Bitmessage CLI Nov 22 00:22 2
mailchuck question Nov 21 08:52 2
Incoming connections Nov 21 02:18 5
(no subject) Nov 20 17:07 7
(no subject) Nov 20 13:14 4
BitMessage crash Nov 19 12:50 7
Alternative Bitmessage port for official assignment with IANA? Nov 19 08:28 5
Tor replacement Nov 18 23:04 5
codewordtest2 Nov 17 21:52 1