This commit introduces a few changes regarding users accessing communities: While the APIs still exist, community invites should no longer be used, instead communities should merely be "shared". Sharing a community to users allows users to "join" the community, which in reality makes them request access to that community. This means, users have to request access to any community, even if the community has permissions set to NO_MEMBERSHIP Only difference between ON_REQUEST and NO_MEMBERSHIP is that ON_REQUEST communities require manual approval of the owner/admin to access a community. NO_MEMBERSHIP communities accept automatically (as soon as owner/admin receives the request). This also implies that users are no longer optimistically added to the member list of communities, but only after they have been accepted. This introduces a bit of a message ping-pong for users to know that someone is now part of a community |
||
---|---|---|
.. | ||
migrations | ||
README.md | ||
cleaner.go | ||
cleaner_test.go | ||
db_key.go | ||
db_key_test.go | ||
limiter.go | ||
limiter_test.go | ||
mailserver.go | ||
mailserver_db.go | ||
mailserver_db_leveldb.go | ||
mailserver_db_leveldb_test.go | ||
mailserver_db_postgres.go | ||
mailserver_db_postgres_test.go | ||
mailserver_test.go | ||
metrics.go | ||
request.go |
README.md
MailServer
This document is meant to collect various information about our MailServer implementation.
Syncing between mail servers
It might happen that one mail server is behind other due to various reasons like a machine being down for a few minutes etc.
There is an option to fix such a mail server:
- SSH to a machine where this broken mail server runs,
- Add a mail server from which you want to sync:
# sudo might be not needed in your setup
$ echo '{"jsonrpc":"2.0","method":"admin_addPeer", "params": ["enode://c42f368a23fa98ee546fd247220759062323249ef657d26d357a777443aec04db1b29a3a22ef3e7c548e18493ddaf51a31b0aed6079bd6ebe5ae838fcfaf3a49@206.189.243.162:30504"], "id":1}' | \
sudo socat -d -d - UNIX-CONNECT:/docker/statusd-mail/data/geth.ipc
- Mark it as a trusted peer:
# sudo might be not needed in your setup
$ echo '{"jsonrpc":"2.0","method":"shh_markTrustedPeer", "params": ["enode://c42f368a23fa98ee546fd247220759062323249ef657d26d357a777443aec04db1b29a3a22ef3e7c548e18493ddaf51a31b0aed6079bd6ebe5ae838fcfaf3a49@206.189.243.162:30504"], "id":1}' | \
sudo socat -d -d - UNIX-CONNECT:/docker/statusd-mail/data/geth.ipc
- Finally, trigger the sync command:
# sudo might be not needed in your setup
$ echo '{"jsonrpc":"2.0","method":"shhext_syncMessages","params":[{"mailServerPeer":"enode://c42f368a23fa98ee546fd247220759062323249ef657d26d357a777443aec04db1b29a3a22ef3e7c548e18493ddaf51a31b0aed6079bd6ebe5ae838fcfaf3a49@206.189.243.162:30504", "to": 1550479953, "from": 1550393583, "limit": 1000}],"id":1}' | \
sudo socat -d -d - UNIX-CONNECT:/docker/statusd-mail/data/geth.ipc
You can add "followCursor": true
if you want it to automatically download messages until the cursor is empty meaning all data was synced.
Debugging
To verify that your mail server received any responses, watch logs and seek for logs like this:
INFO [02-18|09:08:54.257] received sync response count=217 final=false err= cursor=[]
And it should finish with:
INFO [02-18|09:08:54.431] received sync response count=0 final=true err= cursor=[]