[WIP] Start conversations with Facebook users

[MartenBE]

So this is my first version of the functionality to start conversations with facebook users (See #2).

What is works?

• Everything that already worked
• Avatars will now show up for facebook users
• When matrix-puppet-facebook is working, the fb users are listed as online.
• By starting a direct start with a facebook user listed in the status room, a conversation can be initiated without having to use facebook or messenger (so matrix will start the conversation).

What doesn't work?

• Everything else. This code should thoroughly be tested. For example, what happens if the direct chat was already initiated (by the puppet, or by fb)? Will join or crash? What happens if everybody leaves #[email protected] (the alias still exists, can we reuse it)? etc. etc. etc.
• The code is very probably shit. I know almost nothing about JS or Node, so I had to dive in and learn it all. The various libraries matrix-sdk-js, matrix-appservice-bridge, matrix-puppet-bridge, and matrix-puppet-facebook are very confusing for newbies; which library does what? Probably some stuff I did here is already available as functions somewhere or I forgot to set some settings.

Although it is WIP (it is not in a merge state yet), it is a start and proofs this is possible. Right know, I need people to try and test it, and more experienced developers home in the matrix bridge matters to look at the code and how it can be improved.

@martijn:martijn.freeddns.org

[thomas-profitt]

Thanks! I'll see if I can badger any matrix-puppet-facebook users into testing.

This is something the other matrix-puppet-bridge bridges need too, so we'll probably want to take this and abstract some stuff out into matrix-puppet-bridge for the other bridges to implement once this implementation stabilizes. Really exciting!

[cloudrac3r]

I've done a bit of testing.

Working things as of this change:

• You can initiate a chat from Matrix. Yay!
• Room avatars are indeed created.

Not working things that should probably be fixed in this PR:

• Opening a second direct chat with the puppet user in Matrix does not do anything. Messages sent in the new room vanish into the void. The new room does not appear in Facebook. The old room remains perfectly functional.
• While the room avatar is set, its name is not.

Not working things that didn't work before:

• Leaving the room means you can never chat in there ever again, unless you use the puppet to invite yourself back to the room, which you cannot do without editing the bridge code.[1] It would be useful to be able to somehow invite yourself back again.
• Opening a new direct chat after leaving the old room gives the same non-functional room as before.
• Read receipts from FB to Matrix do not work. Matrix to FB does work.
• Reactions do not work.
• Removing messages in Matrix does not remove them in FB.
• Editing messages in Matrix resends the new content in FB.

---

[1] For future reference, here is the code needed to do this:

1. Set up a prompt. Add this code after "matrix-side listening" in index.js.

   const util = require("util");
   process.stdin.on("data", function(input) {
   input = input.toString();
   try {
   let result = eval(input);
   console.log(util.inspect(result, {depth: 1}));
   } catch (e) {
   console.log("Error in eval.\n"+e.stack);
   }
   });

2. Get the room ID. You can get this from historical or from the bridge error room. Room IDs look like this: !zklWWWWWXXXXAPoiuE:example.org

3. Copy that ENTIRE ID, including leading ! and homeserver URL. Paste it into the terminal like this: roomid = "WRITE_THE_ROOM_ID_HERE"

4. Paste this code. app.getIntentFromApplicationServerBot().getClient().invite(roomid, app.puppet.getClient().credentials.userId). You'll immediately be sent an invite back to the room. Accept the invite. The room will work again.

[MartenBE]

Nice, thanks for the feedback! I'll try this out soon!
I also noticed a high CPU usage on my server by using this branch, but I have to dig if it is caused by the code additions in this branch or was already there when using this bridge.

[cloudrac3r]

Today I added someone as a friend, and it took about 7 hours for them to be added to the status room. I've found that I can also stop and restart the bridge to do that same thing. Is it possible to detect when I add a friend on Facebook, or could you set up polling for new friends every few minutes, so that they can be added to the status room quickly?

[cloudrac3r]

Uploading an image to a puppeted room sends it to Facebook once as expected, but a few seconds later, a duplicate image appears on the Matrix end without affecting Facebook. I'm pretty sure this has only started happening since I switched to your fork.

[MartenBE]

Today I added someone as a friend, and it took about 7 hours for them to be added to the status room. I've found that I can also stop and restart the bridge to do that same thing. Is it possible to detect when I add a friend on Facebook, or could you set up polling for new friends every few minutes, so that they can be added to the status room quickly?

As it now works, it only checks your friends list at login. The reason that it took 7 hours is that the start.sh script restarts the bridge regularly. Unfortunately, getting the friends list and parsing their data is rather CPU intensive and takes a long time (this is the high CPU usage i noticed in my previous comment). We should look into that also.

[MartenBE]

Okay, so I added a new commit. This commit should fix the naming of rooms.
Also important, it provides a way to make sure the original room will be used even if multiple direct chats with a friend are initiated. When it detects you initiate a new direct chat, it will create a room with a warning that this room is not connected to fb and invites you back into the original room with the right alias which is connected to fb. Hopefully this works for all edge cases, so please try it out @cloudrac3r .
Next up is the reduce of cpu when going over the friends list, but I am not sure if I can prevent that ...

Edit: Closer inspection indicates that the starting of ghost clients is the culprit, however they need to be started in order to detect invitations in direct chats. I've got about 500 contacts and this crashes after starting around 400 clients (memory errors with the heap). This causes the start.sh script to reboot and start again with starting clients, hence the continuous high CPU. If we could reduce the footprint of ghostClient.startClient(), we could speed up boot, prevent memory errors, and allow direct chat initialization.

Edit 2: There is still an issue with aliases being set when ghost clients are invited to group chats.

[cloudrac3r]

Sorry, I only just saw the notice about this. This sounds great! I'll add testing this to my to-do list.

[MartenBE]

As I have stopped using this bridge some time ago and have received little feedback on the PR, I have ceased to develop my code further. If someone can use this code, please go ahead.