Explain lack of sync alternatives in FAQ

Following issue #128, this explains the lack of synchronous alternatives
to the new API calls.

This issue established, that while the low level interactions will
provide support for both sync and async, any non-related functionalities
that potentially could use an async version will only have an async
version, lowering the burden of maintaining these.

changes/129.docs.md

@@ -0,0 +1 @@
+Mention lack of synchronous alternatives for certain functions (see issue #128)

docs/pages/faq.rst

@@ -1,4 +1,21 @@
 Frequently Asked Questions
 ==========================
 
-There aren't any questions here yet. Feel free to help us change that and propose some!
+.. note::
+  This page is still being worked on, if you have any suggestions for a question, feel free to create an issue on
+  GitHub, or let us know on the development discord server.
+
+Missing synchronous alternatives for some functions
+---------------------------------------------------
+
+While mcproto does provide synchronous functionalities for the general protocol interactions (reading/writing packets
+and lower level structures), any unrelated functionalities (such as HTTP interactions with the Minecraft API) will only
+provide asynchronous versions.
+
+This was done to reduce the burden of maintaining 2 versions of the same code. The only reason protocol intercation
+even have synchronous support is because it's needed in the :class:`~mcproto.buffer.Buffer` class. (See `Issue #128
+<https://github.com/py-mine/mcproto/issues/128>`_ for more details on this decision.)
+
+Generally, we recommend that you just stick to using the asynchronous alternatives though, both since some functions
+only support async, and because async will generally provide you with a more scalable codebase, making it much easier
+to handle multiple things concurrently.