Asbo

Заливать архивом: zip или tar.
Распаковать можно через SSH или файловый менеджер у хостера.
Хороший FTP-клиент - это FileZilla.

Вопрос хороший, но неправильно сформулирован.
Поскольку тут на самом деле два вопроса - какой драйвер использовать и уже потом - как правильно соединяться.
Ответ на первый вопрос очевиден. Если выбирать из mysql_connect, mysqli и PDO, то достаточно зайти на страницу мануала, посвященную каждому варианту, и посмотреть, что там написано. Ну или попробовать использовать в своем коде и посмотреть что получится.

А вот вопрос, как правильно подключаться в двух оставшихся вариантах, действительно важный, и ответ на него, как обычно, почти никто не знает, поскольку все друг у друга списывают статьи не 2-х, а 22-х летней давности. К счастью, есть сайты с актуальной информацией.

Теоретически, можно использовать mysqli. Но не нужно. Потому что это низкоуровневый драйвер и пользоваться им без подготовки очень неудобно. Но если вот прям так приспичило, то вот как правильно соединяться используя mysqli

Ключевые моменты:
- необходимо задавать режим выброса исключений
- необходимо задавать кодировку
- при подключении необходимо перехватывать исключение и выбрасывать его снова, чтобы в сообщении об ошибке не было логина и пароля.

Но правильным ответом, если выбирать из перечисленных трех, будет PDO. Здесь тоже не так просто, поэтому смотрим как правильно соединяться используя PDO - учитывая те же ключевые моменты, которые указаны выше.

Хорошим вариантом будет использовать высокоуровневую абстракцию типа redbean. Но поскольку нормальной документации по нему нет, а есть только пара хайповых видео, где он используется, причем без каких бы то ни было объяснений и разбора основ, то я бы рекомендовал редбин уже опытному разработчику, а не начинающему. Но в любом случае как в нем соединяться, написано в документации

Пароль в базе данных не шифруется а хэшируется. Делается это с посощью функции password_hash

Я думаю это зависит от того кикие ощущения вы хотите иметь когда закончите.
Если напишете на erlange будете куртым
Напишете на go или node.ja будуте хипстором
На java/python будете скучным
На php будете унылым
На С/С++ станете аксакал

Так получается потому, что в современном мире, что бы показать сетевые возможности языка, пишут, что то простое и понятное всем. Раньше это были echo серверы, а теперь это чаты.

Что касаеться певого вопроса, то по абривиатуре XMPP думаю можно нагуглить исходники серверов и клиеентов на любых языках.

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

> Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

Еще две вещи напоследок:
1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.

Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

interface FileSystemInterface {
  public function write($file, $data);
  public function read($file);
}

Затем, хочу реализацию интерфейса ФС для работы с файликами:

class OSFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем файлик, пишем данные
  }

  public function read($file) {
    // открываем файлик, возвращаем данные
  }
}

Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:

class CloudFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем соединение с облаком, пишем данные
  }

  public function read($file) {
    // открываем соединение с облаком, возвращаем данные
  }
}

Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

class FileStorage {
  protected $Fs;
  
  public function __construct(FileSystemInterface $Fs) {
    $this->Fs = $Fs;
  }  

  public function saveFile() {
    $this->Fs->write('file.txt', 'file data');
  }

  public function getFile() {
    return $this->Fs->read('file.txt', 'file data');
  }
}

Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

// Хранилище файлов работает с файловой системой ОС:
$FS = new OSFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

// Хранилище файлов работает с файловой системой в облаке:
$FS = new CloudFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

Использование интерфейса, в данном случае. позволяет нам писать только реализацию работы файловой системы, а бизнес-логика, работающая с файловой системой никак не меняется, она знает, что в любом случае файловая система реализует интерфейс FileSystemInterface и может без опаски использовать методы этого интерфейса.

С точки зрения архитектуры:

Интерфейс описывает свойства. Обратите внимание на классические названия интерфейсов: Throwable, Countable, Comparable, Iterable и т.д. Возьмем, к примеру, интерфейс Rollable (катящийся), и Foldable (складывающийся).

Абстрактный класс же описывает сущность. Например, стол: Table_Abstract. Стол может быть деревянным, тогда будет Table_Wood extends Table_Abstract. Также стол может быть хирургическим: Table_Surgical extends Table_Abstract. В таком случае Table_Abstract объединяет общий свойства всех столов (скажем, площадь поверхности, наличие ножек и т.п.). А конкретный класс описывает сущность определенного типа столов.

Связью же интерфейсов и классов Вы описываете свойства. Например, стол можно катить: Table_Abstract implements Rollable. Деревянный стол, например, можно сложить: Table_Wood implements Foldable.

Шифровать, ключ хранить не в БД а в каком-то конфиге.

Можно сделать отдельный микросервер с ключами.

1. serialize/unserialize (для хранения в БД самое то)
2. JSON (если нужен обмен через AJAX без преобразований)

У сессий только одно назначение - шаринг данных между запросами и различными компонентами.

Куки для этого не годятся по нескольким причинам:
1 и главная - куки будут доступны только после перезагрузки страницы.
2 ненужный трафик. это не смертельно, но только пока проект только для хомяков.
3 не секурно. можно конечно шифровать, но зачем?
4 куки не резиновые, у них есть лимит.