Nov 11 23:23
How do I obtain database of all historical bitmessages?
Nov 11 23:28
This question has been asked before. The nerds in the community refuse to answer it. They feel a sense of power in being able to deny you what you seek.
Nov 12 07:46
Nov 12 09:33
Yes, impossible. The old messages have gone forever, and they won't come back. Ever.
Nov 12 10:49
It has been answered time and time again. If there's no-one that offers it, you can't. The network doesn't store all of it, beamstat neither, and 3-letter agencies who might don't care about you.
Nov 12 12:39
If you are serious about this, make an offer.
Nov 12 12:44
Nov 12 13:27
Why would anybody want your penis? It's not twitter or facebook, no fags here.
Nov 12 13:34
Sorry, wrong address. I was writing to your mother.
Nov 12 13:41
What is it with gay men and their mothers
Nov 12 13:43
Stop polluting bitmessage chan with bullshit. Thank you.
Nov 12 18:53
Overall it is a good thing that very old bitmessages cannot be recovered. It also prevents the messages.dat file from becoming huge with messages that most people would not want to read anyway. It keeps the bitmessage network resources running efficiently, but it is important to remember that there is a 48 hour limit on storage, so you would have to connect at least once every 48 hours to ensure receiving all of your messages.
Nov 12 18:56
Akshully The storage is limited by a message's PoW quality, and there's a hard limit of that of 28 days. Most messages, to my knowledge, are sent with a 4 day PoW.
Nov 12 19:09
Sorry if I've got this wrong, as I was looking at what it says at https://www.bitmessage.org/wiki/FAQ#Can_I_send_a_message_to_someone_that_is_offline which is "Can I send a message to someone that is offline? Yes. However, if you go offline then they must come back online within 2 days of the message being sent. Nodes delete data, and do not accept data, older than 2 days." In this case there appears to be a 48 hour limit. If you aren't sure that either you or the recipient will be online with Bitmessage regularly, it's better to send a PGP encrypted email. This is one of the drawbacks of Bitmessage, as the messages aren't stored on a server and don't last forever.
Nov 12 19:15
Huh, so it says. That would make me assume that this information is either wildly outdated or wildly incorrect.
Nov 12 19:47
You're right, the default TTL (time to live) in the current version of Bitmessage is four days, screenshot here: http://www.picpaste.com/bitmessage_TTL-2Tfg75D1.PNG . However, I wonder how this interacts with the going offline situation mentioned in the Bitmessage FAQ. Clarification from Peter Šurda needed here.
Nov 12 20:17
The default TTL is 4.5 days. The GUI rounds so you see it as 4. User to user messages have a retransmit mechanism. The recipient is supposed to return an acknowledgement to the sender. The sender will retry delivery (send a message again when the old one expires without being acked) until his own maximum expiration time is exceeded. Please consult the "Resends expire" tab in the settings window. Messages to chans and broadcasts don't have a retransmit. The recipient can also turn it off by specifying "dontsendack" in the corresponding address section in keys.dat. The protocol does not mandate that the sender waits for the acknowledgement but pybitmessage does as specified above. I opened a ticket to update the wiki. Peter Surda Bitmessage core developer
Nov 12 20:21
Thank you for clarifying, Peter.
Nov 12 22:38
ttl = 367200 4.25 days
Nov 13 05:48
I don't think many people are going to worry about the difference between 4.25 and 4.5 days. The real problem is that if a person goes away on a week's holiday and doesn't connect to bitmessage, some messages might be lost. This is something that the system needs to make clear to newbies, because unlike emails the messages won't be stored for weeks, month or years.
Nov 13 11:30
Looks like I can't round. Or divide. Or both. Peter Surda Bitmessage core developer
Nov 13 11:31
> I don't think many people are going to worry about the difference > between 4.25 and 4.5 days. The real problem is that if a person goes > away on a week's holiday and doesn't connect to bitmessage, some > messages might be lost. This only affects broadcasts, chans, people who don't want to send acknowledgements and senders who have a low retransmit expiration. > This is something that the system needs to > make clear to newbies, because unlike emails the messages won't be > stored for weeks, month or years. Maybe, but if you can't be bothered to check personal messages for months then you probably don't find them that important. Peter Surda Bitmessage core developer
Nov 13 11:35
Well, in the screenshot it says, among other things, "If your Bitmessage client does not hear an acknowledgement, it will resend the message automatically." Maybe if I fix the layout, it will be more obvious. Peter Surda Bitmessage core developer
Nov 13 11:59
Happens to the best of us.
Nov 13 18:57
When I went to holiday and forgot keys.dat with my favourite chans I run fresh BM and copy messages.dat for every 3-4 days. When I came back to home I changed date and connect my original BM to BM with copied messages. So some people want to know how many days are default in BM.
Nov 14 14:54
Bullshit. There are dozens of people who have been running 24/7 server nodes. You know damn well they are archiving all the objects. Stingy fuckers.
Nov 14 15:00
I know damn well that the procotol says "Any node working to specs will drop objects from it's inventory, which exceeded their time to live", which is what I meant with "the network doesn't store all of it". If they are archiving it, it's not in the specs, so they'd have to offer this archive to you as an extra service, which is what I meant with "If there's no-one that offers it, you can't".
Nov 15 08:43
You also need a client that understands the extra service - at the very least you need a client that accepts objects that expired more than an hour ago.
Jan 6 04:29
is the proper format "dontsendack = True" ?
Jan 6 08:24
now this is truely fuclong amazing. a wiki is supposed to be FAST, Okay? if opening a ticket is faster than editing the wiki something is either wrong with the FUCKING BM WIKI POLICY or with the language of native New Zealanders
|did you always want to edit a file ? 100 lines release !||Jan 22 15:50||3|
|CPU time : connection frequency - patch||Jan 22 15:40||6|
|CPU time : connection frequency||Jan 22 13:31||7|
|the exception caused by UTF-8 characters in logging||Jan 22 12:39||1|
|CPU time : connection frequency ?||Jan 22 06:20||5|
|MESSAGE ENCRYPTION ENHANCEMENTS FOR BITMESSAGE||Jan 21 05:15||1|
|chan Procedure Nazi Dumb Blonde SuperDick||Jan 19 19:31||3|
|RFC: lighting payments on mailchuck email gateway||Jan 19 13:38||6|
|BM CPU time||Jan 19 08:39||12|
|Protonmail integration with Bitmessage||Jan 19 02:24||8|
|bitmessage debian install script||Jan 18 23:56||2|
|Layout and Formatting Feature Requests||Jan 18 02:19||1|
|Feature Request||Jan 18 01:12||1|
|help me modify my bitmessage||Jan 18 00:08||4|
|Public announcement||Jan 17 05:19||7|
|[chan] 411 BM-2cW53MzWqtod8TA6vybdUeqd2LhTuXCX3L||Jan 17 01:02||1|
|Multiple addresses and anonymity||Jan 16 16:47||12|
|need help broke af||Jan 15 18:56||8|
|randomize exchange of bitmessage objects||Jan 14 13:32||3|
|python IDE||Jan 13 12:42||2|
|suggestion : "private DML"||Jan 13 12:39||1|
|mailchuck spamfilter||Jan 12 18:56||2|
|tor-0.3.2.9 message log warnings||Jan 11 13:46||8|
|Which python IDE are BM devs using ?||Jan 11 07:03||10|
|New functionality request for BitMessage after the trolling of nazi feds of yesterday.||Jan 10 15:47||2|
|New functionality request for BitMessage after the trolling of nazi feds of yesterday on the Crypto-Anarchist chan.||Jan 10 08:03||6|
|emoji only partially supported 🏴☠️🏴☠️||Jan 10 00:51||10|
|New Functionality request [..]||Jan 10 00:33||1|
|how do bitmessage peers find each other on a local network?||Jan 9 08:57||5|
|mailchuck||Jan 7 21:23||11|
|hashionados||Jan 7 01:27||14|
|bitmessage history||Jan 6 08:24||2|
|colored emoji font||Jan 6 07:37||1|
|noncetrialsperbyte||Jan 6 00:38||4|
|STATBOT v0.0 : pings other STATBOTS to measure bitmessage transit times||Jan 6 00:32||6|
|Bitseal||Jan 4 10:37||2|
|Updated: STATBOT v0.0 : pings other STATBOTS to measure bitmessage transit times||Jan 4 09:22||4|
|bitmessage plugin testing||Jan 3 06:57||2|
|BM API - how to check if chan exists in keys.dat||Jan 1 15:23||9|
|Forwarding port 8444, must the IP address be static ?||Jan 1 12:22||10|
|[chan] statbot_pool <BM-2cXrouuaAyw8rzvfc2d4RgoFMn7SjnJBsQ>||Jan 1 08:17||1|
|BONK 31337313373133731337||Jan 1 06:56||1|
|running the 1500 chan mammoth||Dec 31 10:26||3|
|massive BM spike due to Russians||Dec 30 20:41||2|
|The BM network seems to be acting funny||Dec 30 17:12||4|
|fuck me ! The Russians posted 8000 BMs. they OWN bm.||Dec 30 10:35||2|
|ERROR - Unknown state connection_fully_established||Dec 30 09:34||7|
|the glider life can be simulated in your computer !||Dec 30 02:36||3|
|latest commit||Dec 29 19:02||3|
|did you always want to edit a file ?||Dec 29 17:07||3|
|pyBM 0.6.2 new feature kinda pointless||Dec 29 15:26||12|
|py2 py3 problems||Dec 28 18:50||1|
|api / bmconfigparser / keys.dat||Dec 28 12:56||6|
|dontconnect in pyBM 062 not being honoured||Dec 27 22:11||2|
|mammoth||Dec 27 18:40||1|
|want to goof around with data base ?||Dec 27 14:04||1|
|sqlite has betrayed me||Dec 27 06:46||5|
|200 watch, 2000 stars and 500 forks - sow where are the USERS ?||Dec 27 04:22||19|
|DevTalk: pyBM code audit||Dec 27 00:04||1|
|nice BM proggy||Dec 26 19:20||1|
|stay dark on github||Dec 26 16:17||4|
|Bitmessage to Shell||Dec 26 16:07||1|
|CLI||Dec 26 13:54||1|
|so I signed my pull request||Dec 26 13:37||1|
|pygubu tkinter GUI builder||Dec 26 11:34||2|
|clean up pyBM github landing page, please||Dec 26 11:05||8|
|New bitmessage readme||Dec 26 02:22||3|
|new BM GUI to be released||Dec 26 01:59||1|
|DEMONSAW The Future is Clear PROMETHER The End of Surveillance||Dec 25 21:56||1|