New Provider DB

some thoughts about the new data structure for the provider db I brainstormed together with @compl4xx

  • Message about limits (shown in the device chat)
    • maximum message size
  • 2 types of preperation steps to show users: pre-login and post-login
    • pre-login examples: Enabling IMAP/SMTP, getting an ‘app password’ for DeltaChat to use
    • post-login examples: change default inbox at the provider settings to prevent webde from moving to unknown folder, ?spam settings?
  • name
  • domains
  • credentials: emailPass or OAuth2 or AppPassword?
  • status: (most recent?)
    • OK, PREP, BROKEN
    • date
  • web-only
    • optional extra markdown file for tutorials on the web with embed images/videos? (maybe rather link to a webpage in device chat)
    • registration
      • identification requirements (phonenumber, passport, postal adress)
      • bussiness model: ad financed, paid, community funded, donations, government funded
    • benchmark results
      • average message transmission speed?
    • comments for results like on protondb (currated, moderated)
    • popularity (how often is it searched for in google? searchstat.com)

In the long run

  • Values for the core to use:
    • supports burner accounts api data/method
    • ?rate limiting (maybe show a counter how many message you can still send per day (sms like))
    • Connection data
      • own data - like force disable TLS for cuba.
      • Autoconfigure data from Tunderbirds autoconfigure db
3 Likes

nice overview. i think the connection data (port, server etc.) can be added in the short term already.

2 Likes

related github issues:
provider-db#42 provider-db#44 provider-db#45

1 Like

I’d add the database entry “maximum message size”.

i have to clarify my post from above: while i still think, it is a nice overview of possibilities, i think it is actually a bit too much we can really take care for. i think, esp. in the first time, we have to maintain the database, at least for the bigger providers, ourself.

i would reduce the database strictly to what we really need in the first step in the app.

also, i would add dedicated, separate fields only as really needed - classifying everything is a table sounds nice and correct, however, in practice, all these nice classifications often do not work out and you need even more fields.

so, my suggestion is: separate fields only for things actually proven to be needed by the apps, the rest can go to a freetext field.