forked from cadence/out-of-your-element
Comparison of all the stuff I did. #6
3 changed files with 6 additions and 6 deletions
|
|
@ -25,15 +25,15 @@ async function threadToAnnouncement(parentRoomID, threadRoomID, creatorMxid, thr
|
||||||
if (branchedFromEventID) {
|
if (branchedFromEventID) {
|
||||||
// Need to figure out who sent that event...
|
// Need to figure out who sent that event...
|
||||||
const event = await di.api.getEvent(parentRoomID, branchedFromEventID)
|
const event = await di.api.getEvent(parentRoomID, branchedFromEventID)
|
||||||
suffix = "\n\n[Note: You should talk there, rather than in this newly-created Matrix thread. Any messages sent here will be bridged as replies, which is probably not what you want.]";
|
suffix = "\n[Note: You should continue the conversation in that room, rather than in this thread. Any messages sent in Matrix threads will be bridged to Discord as replies, not in-thread messages, which is probably not what you want.]";
|
||||||
context["m.relates_to"] = {"m.in_reply_to": {event_id: event.event_id}, is_falling_back:false, event_id: event.event_id, rel_type: "m.thread"}
|
context["m.relates_to"] = {"m.in_reply_to": {event_id: event.event_id}, is_falling_back:false, event_id: event.event_id, rel_type: "m.thread"}
|
||||||
if (event.sender && !userRegex.some(rx => event.sender.match(rx))) context["m.mentions"] = {user_ids: [event.sender]}
|
if (event.sender && !userRegex.some(rx => event.sender.match(rx))) context["m.mentions"] = {user_ids: [event.sender]}
|
||||||
}
|
}
|
||||||
|
|
||||||
const msgtype = creatorMxid ? "m.emote" : "m.text"
|
const msgtype = creatorMxid ? "m.emote" : "m.text"
|
||||||
const template = creatorMxid ? "started a thread:" : "Thread started:"
|
const template = creatorMxid ? "started a thread" : "New thread started: "
|
||||||
const via = await mxUtils.getViaServersQuery(threadRoomID, di.api)
|
const via = await mxUtils.getViaServersQuery(threadRoomID, di.api)
|
||||||
let body = `${template} ${thread.name} https://matrix.to/#/${threadRoomID}?${via.toString()}${suffix}`
|
let body = `${template} „${thread.name}” in room: https://matrix.to/#/${threadRoomID}?${via.toString()}${suffix}`
|
||||||
|
|
||||||
return {
|
return {
|
||||||
msgtype,
|
msgtype,
|
||||||
|
|
|
||||||
|
|
@ -222,9 +222,9 @@ async event => {
|
||||||
}
|
}
|
||||||
if (event.content["m.relates_to"]?.rel_type === "m.thread" && executedCommand !== "thread"){
|
if (event.content["m.relates_to"]?.rel_type === "m.thread" && executedCommand !== "thread"){
|
||||||
api.sendEvent(event.room_id, "m.room.message", {
|
api.sendEvent(event.room_id, "m.room.message", {
|
||||||
"body": "⚠️ **This message may not have bridged to Discord in the way you thought it would!**\n\nIt seems like you sent this message inside a Matrix thread. Matrix threads don't work like Discord threads - they are effectively just „fancy replies”, not independent rooms/channels (any „thread-like appearance” is handled purely client-side - and even then, most Matrix clients don't handle it particularly well), and as such, they are bridged as replies to Discord. _Discord users will not be aware that you sent this message inside a thread - it will go directly onto the main channel. If the thread you sent this message in is old, such a random reply may be distracting to Discord users!_\n\nFor the sake of Discord parity (as well as better support in numerous Matrix clients - as stated above, most Matrix clients don't handle threads particularly well, and they just render in-thread messages as fancy replies), it is recommended to send threaded messages inside a separate Matrix room that gets bridged to Discord. If you sent this message in a pre-existing Matrix thread, please look around to see if anyone has created such a room for it. If this is the first message (ie. the thread was just created) or noone's made a thread-room for this thread, it is recommended you create one with `/thread <Thread Name>` (on Matrix) and continue the conversation there.\n\n*You can read more about the rationale behind this design choice [here](https://gitdab.com/cadence/out-of-your-element/src/branch/main/docs/threads-as-rooms.md).*",
|
"body": "⚠️ **This message may not have been bridged to Discord in the way you thought it was gonna be!**\n\nIt seems like you sent this message inside a Matrix thread. Matrix threads don't work like Discord threads - they are effectively just „fancy replies”, not independent rooms/channels (any „thread-like appearance” is handled purely client-side - and even then, most Matrix clients don't handle it particularly well), and as such, they are bridged as replies to Discord. *Discord users will not be aware that you sent this message inside a thread - it will go directly onto the main channel. If the thread you sent this message in is old, such a random reply may be distracting to Discord users!*\n\nFor the sake of Discord parity (and for better support in numerous Matrix clients - as stated above, most Matrix clients don't handle threads particularly well, and they just render in-thread messages as fancy replies), it is recommended to send threaded messages inside a separate Matrix room that gets bridged to Discord. If you sent this message in a per-existing Matrix thread, please look around to see if anyone has created such a room for it. If this is the first message (ie. the thread was just created) or nobody has made a thread-room for this thread yet, it is recommended you create one with `/thread <Thread Name>` (on Matrix) and continue the conversation there. You can even run this command directly in this very Matrix thread, and the new Discord thread will be automatically attached to the same message as this one (alternatively, run that command outside a thread and as a reply to a different message to attach the thread to that message, or stand-alone to create a stand-alone thread).\n\n*You can read more about the rationale behind this design choice [here](https://gitdab.com/cadence/out-of-your-element/src/branch/main/docs/threads-as-rooms.md).*",
|
||||||
"format": "org.matrix.custom.html",
|
"format": "org.matrix.custom.html",
|
||||||
"formatted_body": "⚠️ <strong data-md=\"**\">This message may not have bridged to Discord in the way you thought it would!</strong><br/><br/>It seems like you sent this message inside a Matrix thread. Matrix threads don't work like Discord threads - they are effectively just „fancy replies”, not independent rooms/channels (any „thread-like appearance” is handled purely client-side - and even then, most Matrix clients don't handle it particularly well), and as such, they are bridged as replies to Discord. <i data-md=\"_\">Discord users will not be aware that you sent this message inside a thread - it will go directly onto the main channel. If the thread you sent this message in is old, such a random reply may be distracting to Discord users!</i><br/><br/>For the sake of Discord parity (as well as better support in numerous Matrix clients - as stated above, most Matrix clients don't handle threads particularly well, and they just render in-thread messages as fancy replies), it is recommended to send threaded messages inside a separate Matrix room that gets bridged to Discord. If you sent this message in a pre-existing Matrix thread, please look around to see if anyone has created such a room for it. If this is the first message (ie. the thread was just created) or noone's made a thread-room for this thread, it is recommended you create one with <code data-md=\"`\">/thread <Thread Name></code> (on Matrix) and continue the conversation there.<br/><br/><i data-md=\"*\">You can read more about the rationale behind this design choice <a data-md href=\"https://gitdab.com/cadence/out-of-your-element/src/branch/main/docs/threads-as-rooms.md\">here</a>.</i>",
|
"formatted_body": "⚠️ <strong data-md=\"**\">This message may not have been bridged to Discord in the way you thought it was gonna be!</strong><br/><br/>It seems like you sent this message inside a Matrix thread. Matrix threads don't work like Discord threads - they are effectively just „fancy replies”, not independent rooms/channels (any „thread-like appearance” is handled purely client-side - and even then, most Matrix clients don't handle it particularly well), and as such, they are bridged as replies to Discord. <i data-md=\"*\">Discord users will not be aware that you sent this message inside a thread - it will go directly onto the main channel. If the thread you sent this message in is old, such a random reply may be distracting to Discord users!</i><br/><br/>For the sake of Discord parity (and for better support in numerous Matrix clients - as stated above, most Matrix clients don't handle threads particularly well, and they just render in-thread messages as fancy replies), it is recommended to send threaded messages inside a separate Matrix room that gets bridged to Discord. If you sent this message in a per-existing Matrix thread, please look around to see if anyone has created such a room for it. If this is the first message (ie. the thread was just created) or nobody has made a thread-room for this thread yet, it is recommended you create one with <code data-md=\"`\">/thread <Thread Name></code> (on Matrix) and continue the conversation there. You can even run this command directly in this very Matrix thread, and the new Discord thread will be automatically attached to the same message as this one (alternatively, run that command outside a thread and as a reply to a different message to attach the thread to that message, or stand-alone to create a stand-alone thread).<br/><br/><i data-md=\"*\">You can read more about the rationale behind this design choice <a data-md href=\"https://gitdab.com/cadence/out-of-your-element/src/branch/main/docs/threads-as-rooms.md\">here</a>.</i>",
|
||||||
"m.mentions": { "user_ids": [event.sender]},
|
"m.mentions": { "user_ids": [event.sender]},
|
||||||
"m.relates_to": {
|
"m.relates_to": {
|
||||||
"event_id": event.content["m.relates_to"].event_id,
|
"event_id": event.content["m.relates_to"].event_id,
|
||||||
|
|
|
||||||
|
|
@ -261,7 +261,7 @@ const commands = [{
|
||||||
|
|
||||||
const relation = event.content["m.relates_to"]
|
const relation = event.content["m.relates_to"]
|
||||||
let attachedToEvent = relation?.["m.in_reply_to"]?.event_id // By default, attempt to attach the thread to the message to which /thread was replying.
|
let attachedToEvent = relation?.["m.in_reply_to"]?.event_id // By default, attempt to attach the thread to the message to which /thread was replying.
|
||||||
if (relation?.rel_type === "m.thread" && relation.is_falling_back) attachedToEvent = event.content["m.relates_to"]?.event_id // If /thread was sent inside a Matrix thread, attempt to attach the Discord thread to the message around which that Matrix thread was based on. But only if we're falling back, ie. the message sent in that thread was a „normal” one, not a reply to some other message inside the thread. If it WAS reply, we preserve the original behavior (attach the thread to the message to which /thread was replying). One slight caveat is that is_falling_back will also be false if it's the 1st message of that thread. In such case, however, m.in_reply_to should (if sent from a spec-compliant client) point towards the message around which that Matrix thread was based on, so the intended behavior is preserved.
|
if (relation?.rel_type === "m.thread") attachedToEvent = event.content["m.relates_to"]?.event_id // If /thread was sent inside a Matrix thread, attempt to attach the Discord thread to the message around which that Matrix thread was based on.
|
||||||
if (!attachedToEvent) attachedToEvent = event.event_id // If /thread wasn't replying to anything (ie. attachedToEvent was undefined at initial assignment), or if the event was somehow malformed (in such a way that that - one way or another - attachedToEvent ended up being undefined, even if according to the spec it shouldn't), attach the thread to the /thread command-message that created it.
|
if (!attachedToEvent) attachedToEvent = event.event_id // If /thread wasn't replying to anything (ie. attachedToEvent was undefined at initial assignment), or if the event was somehow malformed (in such a way that that - one way or another - attachedToEvent ended up being undefined, even if according to the spec it shouldn't), attach the thread to the /thread command-message that created it.
|
||||||
|
|
||||||
assert(attachedToEvent)
|
assert(attachedToEvent)
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue