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.
|Tor replacement||Nov 17 22:30||1|
|codewordtest2||Nov 17 21:52||1|
|bitmessage history||Nov 15 08:43||28|
|stream and pool diagram||Nov 12 12:05||21|
|( ͠° ͟ ʖ ͡°)||Nov 10 09:51||2|
|I'm back.||Nov 9 17:55||1|
|streams and pools||Nov 7 01:37||1|
|How to examine bitmessage objects||Nov 7 00:45||5|
|Tor curve vs bm curve||Nov 7 00:45||4|
|keys.dat values||Nov 6 23:16||2|
|Bitmessage history||Nov 6 08:08||9|
|Pseudo-mailinglist vs chans?||Nov 5 21:47||2|
|bitmessage node rating?||Nov 5 21:32||2|
|can I connect to both onions and standard?||Nov 5 19:33||11|
|Bitmessage won't exit cleanly||Nov 4 18:06||2|
|keys.dat must be encrypted||Nov 4 12:09||12|
|Question||Nov 3 20:09||5|
|It's actually not that hard to de-anonymize someone on bitmessage.||Nov 3 19:49||8|
|It's actually not that hard to de-anonymize someone on||Nov 2 14:18||1|
|Bitmessage snapshots||Nov 2 13:14||3|
|Why chan address?||Nov 1 06:26||2|
|HASH Q||Oct 31 21:16||1|
|bitpetite scam||Oct 31 08:34||2|
|GitHub Supports Islamic Clitoris Removal||Oct 31 01:02||14|
|What exactly is the address of [chan] general?||Oct 30 05:29||7|
|MiNode addr bug||Oct 27 11:53||1|
|Hi, users !||Oct 27 07:18||5|
|No incoming connections now||Oct 26 09:40||33|
|RE: bitmessage implementation in any other programming language||Oct 23 17:01||1|
|disabled address still working||Oct 23 12:47||8|
|apinotifypath||Oct 22 01:11||1|
|checkdeps.py error||Oct 21 22:04||3|
|BM slow suddenly?||Oct 21 15:47||9|